תגובה מהירה: ניפוי מאגרי מידע ופרופילים להצלה

להסיר: המארח אריק קוואנה שוחח על ניפוי מאגרי מידע ופרופיל עם ד"ר רובין בלור, דז בלנשפילד ו- Bert Scalzo.

אינך מחובר כרגע. התחבר או הירשם כדי לראות את הסרטון.

אריק קוואנה: אוקיי, גבירותיי ורבותיי, הגיע השעה 4:00 מזרחי ביום רביעי, וכמובן שזה אומר.

רובין בלור: אני לא יכול לשמוע אותך, אריק.

אריק קוואנה: הייתי שם לפני ימים, אז אתה לא לבד. אבל הנושא היום הוא דברים מעניינים באמת. זה סוג הדברים שאתה רוצה לוודא שקורה ברקע בחברה שלך, אלא אם כן אתה עושה את זה, ובמקרה זה אתה רוצה לוודא שאתה עושה את זה כמו שצריך. כי דיברו על ניפוי באגים. אף אחד לא אוהב באגים, אף אחד לא אוהב כשהתוכנה מפסיקה לעבוד - אנשים מתעצבנים, משתמשים לא ידידותיים. זה לא טוב. אז, התכוונו לדבר על "תגובה מהירה: ניפוי מסדי נתונים ופרופילים להצלה."

יש נקודה עלייך באמת, הכה אותי, @eric_kavanagh כמובן.

השנה חמה. וניפוי באגים הולך להיות חם, לא משנה מה. זה באמת תהיה אחת הבעיות האלה שלעולם לא תיעלם, לא משנה כמה טוב אנו משיגים את הדברים האלה, תמיד יש בעיות, אז המפתח הוא איך מגיעים למקום בו תוכלו לפתור את הבעיות הללו במהירות? באופן אידיאלי, יש לך מתכנתים נהדרים, סביבות נהדרות, שבהם לא יותר מדי משתבש, אך כמו שאומר האמרה הישנה, ​​"תאונות קורות במיטב המשפחות." וזה נכון גם לארגונים. אז הדברים האלה קורים, זה יקרה, השאלה היא מה הולך להיות הפיתרון שלך להתמודד עם זה ולפתור את הבעיות האלה?

טוב לשמוע מד"ר רובין בלור, אז דז בלנשפילד משלנו מלמטה, וכמובן, חברנו הטוב, ברט סקלזו, מ- IDERA. ולמעשה, אני הולך למסור את המפתחות לרובין בלור, קח אותו משם. הרצפה שלך.

רובין בלור: בסדר. זה נושא מעניין. חשבתי מכיוון שד''ז כנראה הולך להמשיך לטכניקות ולסיפורי המלחמה בפועל על ניפוי באגים, חשבתי שעדיף רק לקיים דיון ברקע כדי שנוכל לקבל תמונה מעוגלת לחלוטין של הנעשה. עשיתי את זה הרבה זמן והייתי מקודד, כך שזה דומה, וכמעט התפתיתי עם המצגת הזו להתחיל לדעוך לירית לגבי הרעיון של קוד פתוח, אבל חשבתי שאשאיר את זה למישהו אחר.

הנה רשימה של באגים מפורסמים, ורובם נכנסים לרשימה העליונה של anybodys, כולם, למעט שני האחרונים, עולים לפחות 100 מיליון דולר. הראשון היה אורביטר האקלים של מאדים, הלך לאיבוד בחלל וזה נבע מבעיית קידוד, שם אנשים התבלבלו בין יחידות מטריות עם (צוחק) רגליים ואינץ '. בטיסת 501 Ariane חלה אי התאמה בין מנוע שהועלה למחשבים שהיו אמורים להפעיל את הרקטה בעת שיגורו. תקלות מרובות במחשבים, טיל מתפוצץ, חדשות כותרות. צינור הגז הסובייטי בשנת 1982, אמר כי הוא הפיצוץ הגדול ביותר בתולדות כדור הארץ; אני לא בטוח אם זה. הרוסים גנבו תוכנת בקרה אוטומטית, וה- CIA הבינו שהם מתכוונים לעשות זאת ולהכניס לתוכו באגים, והסובייטים יישמו אותה בלי בדיקה. אז, פוצץ צינור, חשבתי שזה משעשע.

תולעת מוריס הייתה ניסוי קידוד, שהפך לפתע לתולעת נלהבת שהסתובבה סביב כולם - היא ככל הנראה גרמה נזק בשווי 100 מיליון דולר; זו הערכה כמובן. אינטל עשתה שגיאה מפורסמת עם שבב מתמטיקה - הוראות מתמטיקה על שבב הפנטיום בשנת 1993 - שהיה אמור לעלות מעל 100 מיליון דולר. תוכנית מפות תפוחים היא אולי ההשקה הגרועה והאסודה ביותר של כל מה שאפל עשתה אי פעם. אנשים שניסו להשתמש בו היו, כוונתי, מישהו נסע לאורך 101 וגילה שמפת התפוחים אמרה שהם היו באמצע מפרץ סן פרנסיסקו. אז אנשים התחילו להתייחס לאפליקציית מפות אפל כ- iLost. ההפסקה הארוכה ביותר שלנו בשנת 1990 - זה פשוט מעניין מבחינת העלות של משהו כזה - AT&T היו בחוץ במשך תשע שעות וזה עלה כשישים מיליון דולר בשיחות למרחקים ארוכים.

והייתי בחברת ביטוח בבריטניה, ובסיס הנתונים, הם יישמו גרסה חדשה של המאגר וזה התחיל למחוק נתונים. ואני זוכר זאת היטב, מכיוון שקראו לי אחר כך לקחת חלק בבחירת סוג מסדי נתונים בגלל זה. וזה היה מאוד מעניין שהם לקחו גרסה חדשה של בסיס הנתונים, והייתה להם סוללת בדיקות שעשו עבור גרסאות חדשות של בסיס הנתונים שהיא עברה את כל הבדיקות. היא מצאה דרך מעורפלת באמת למחוק נתונים.

אז בכל מקרה, זהו. חשבתי שאני מדבר על חוסר ההתאמה של עכבה ו- SQL שהונפק. זה מעניין שמסדי נתונים יחסיים מאחסנים נתונים בטבלאות וקודדים נוטים לתמרן נתונים במבני אובייקטים שבאמת לא ממפים טוב מאוד לטבלאות. ובגלל זה, אתה מקבל מה שנקרא חוסר ההתאמה של עכבה, ומישהו צריך להתמודד עם זה בדרך זו או אחרת. אבל מה שקורה בפועל, מכיוון שמודל אחד, מודל הקודנים ובסיס הנתונים מודל אחר, אינם מיושרים במיוחד. אתה מקבל באגים שפשוט לא היו קורים אם התעשייה בנתה דברים שעובדים יחד, שלדעתי מצחיקים. אז בעצם, בצד המקודדים, כשאתה מקבל היררכיות זה יכול להיות סוגים, זה יכול לגרום לסטים, זה יכול להיות יכולת API לקויה, זה יכול להיות הרבה דברים שפשוט משליכים דברים מבחינת אינטראקציה עם בסיס הנתונים. אבל הדבר שהכי חשוב לי, מעניין באמת; תמיד הדהים אותי שיש לך מחסום SQL זה שהוא גם סוג של עכבה באופן שהקודדים ומסד הנתונים עובדים זה עם זה. אז, ל- SQL זיהוי נתונים, וזה בסדר ויש לו DML לבחירה, פרוייקט והצטרפות, וזה בסדר. אתה יכול לזרוק יכולת רבה מבחינת הוצאת נתונים מהמאגר עם זה. אבל יש לה מעט מאוד שפה מתמטית לביצוע דברים. יש בזה קצת מזה וזה, ויש לו מעט מאוד דברים מבוססי זמן. ובגלל זה, SQL הוא אמצעי לא מושלם, אם תרצו, לקבל את הנתונים. אז, אנשי המסד נתונים בנו נהלים מאוחסנים כדי לחיות בבסיס הנתונים והסיבה להליכים המאוחסנים החיים שם הייתה שלא באמת רצית לזרוק נתונים קדימה ואחורה לתוכנית.

עבור חלק מהפונקציונליות הייתה מאוד ספציפית לנתונים, כך שזה לא היה רק ​​שלמות הפניה ומחיקות מדורגים ודברים כאלה, מסד הנתונים דאג לכל הפונקציונאליות שאתה מכניס פונקציונליות למסד נתונים, מה שאומר כמובן שהתפקוד של ניתן לפצל את היישום בין המקודד למסד הנתונים עצמו. וזה הפך את העבודה ליישום סוגים מסוימים של פונקציות לקשה למדי ולכן נוטה יותר לטעות. אז זה צד אחד של משחק מסד הנתונים, מכיוון שזה אומר שיש לך הרבה יישומים למשל, שהייתי מעורב במאגרי מידע יחסיים, יש באמת הרבה קוד נורא שיושב בפרוצדורות מאוחסנות המטופלות בנפרד מהקוד יושב ביישומים. וזה נראה כמו דבר מוזר מאוד שצריך להגיע אליו, שהוא אמור להיות חכם למדי בעשיית דברים שונים.

חשבתי שמזה מדבר גם על ביצועי בסיס נתונים מכיוון ששגיאות ביצועים נחשבות לרוב כמו באגים, אך בעיקרון אתה יכול לקבל צוואר בקבוק במעבד, בזיכרון, בדיסק, ברשת וייתכן שיש לך בעיות ביצועים בגלל נעילה. הרעיון יהיה שהקודד לא באמת צריך להיות מודאג מביצועים ובסיס הנתונים אכן יבצע ביצועים טובים למדי. זה אמור להיות מעוצב כך שהקודר לא צריך לדעת. עם זאת, אתה מקבל תכנון רע של מסד נתונים, אתה מקבל תכנון רע של תוכניות, אתה מקבל במקביל בערבוב עומסי עבודה, שיכול גם להוביל לבעיות ביצועים. אתה מקבל איזון עומסים, אתה מקבל תכנון קיבולת, גידול נתונים - שיכול לגרום למסד נתונים פשוט להפסיק או להאט. זה דבר מעניין, כאשר מאגרי מידע מלאים כמעט, הם מאטים. ואתה יכול להיות נושא בשכבות נתונים מבחינת השכפול והצורך לשכפל והצורך לבצע גיבוי ושחזור. בכל מקרה, זו סקירה כללית.

הדבר היחיד שהייתי רוצה לומר הוא כי ניפוי באגרי מסד נתונים יכול להיות מכביד ובלתי טריוויאלי בלבד - ואני אומר שבגלל שעשיתי הרבה מזה - ולעיתים קרובות תגלה את זה כמו כל המצבים בבאגינג שאי פעם חוויתי. הוא הדבר הראשון שאתה רואה אי פעם זה בלגן. ואתה צריך לנסות לעבור מהבלאגן כדי להבין כיצד התרחש הבלגן. ולעיתים קרובות כשאתה מסתכל על סוגיית מסד נתונים כל מה שאתה מסתכל עליהם הוא נתונים פגומים ואתה חושב "איך לעזאזל זה קרה?"

בכל אופן, אני אעבור לדצ ', שכנראה הולך לומר יותר דברי חוכמה ממה שיצאתי איתם. אני לא יודע להעביר לך את הכדור, דז.

אריק קוואנה: אני אעבור את זה, לעמוד מעמד, להחזיק מעמד.

קול אוטומטי: שורות המשתתפים השתקו.

אריק קוואנה: בסדר, חכה רגע אחד, הרשה לי לתת לדז את הכדור.

דז בלנשפילד: תודה, אריק. כן, דוקטור רובין בלור, אתה אכן הכי נכון: זה נושא, דבורה לכל החיים אם תסליח על המלים, סליחה שלא יכולתי לעזור לעצמי בנושא הזה. אני מקווה שתוכלו לראות את המסך הראשון שלי שם, את התנצלותי על בעיית גודל הגופן בראש. נושא הבאגים הוא הרצאה לאורך יום, במקרים רבים מניסיוני. זה נושא כה רחב ורחב, אז אני הולך לשים את המוקד על שני תחומי מפתח, במיוחד הרעיון של מה שאנחנו מחשיבים כמו באג, אבל נושא תכנות. אני חושב שבימינו הצגת באג כשלעצמה בדרך כלל נאספת על ידי סביבות הפיתוח המשולבות, אם כי יתכן שמדובר בבאגים ארוכי טווח. אך לעיתים קרובות מדובר במקרה של פרופיל קוד ואפשר לכתוב קוד שמתפקד, זה אמור להיות באג. אז, שקופית הכותרת שלי לכאן, למעשה היה לי עותק של זה ברזולוציה גבוהה מאוד A3, אבל לצערי זה נהרס במהלך מעבר לבית. אך זוהי תו בכתב יד על דף תכנות משנת 1945, שם לכאורה היו אנשים מאוניברסיטת הרווארד בארצות הברית, המכונה השנייה שלהם המכונה מארק השני. הם ניגשו באיזו סוגיה, בשפה המקובלת, אבל הם ניסו למצוא תקלה, ומסתבר שמשהו מעט שונה ממה שהיה חומרה ובנושא כביכול תוכנה.

אז המיתוס האורבני הוא סביב ה 9 בספטמבר^th, 1945 צוות מאוניברסיטת הרווארד פירק מכונה, הם נתקלו במשהו שכינו "ממסר שבעים" - בימים ההם התכנות נעשתה במובן גופני, אתה פיתחת קוד סביב לוח, וככה תכנת בפועל את מכונה - והם מצאו שהממסר הזה מספר שבעים, היה בו משהו לא בסדר, ומתברר שהמונח "באג" נוצר מכיוון שהוא ממש היה עש - כביכול היה תקוע עש בין איזה פיסת חוט נחושת. ממקום אחד לאחר. והסיפור אומר שגרייס הופר האגדית ככיתוב זה, עבור שקופית הכותרת שלי, "המקרה האמיתי הראשון של איתור באג" ציטוט לא ציטוט.

אך כפי שרובין הדגיש מוקדם יותר בשקופית הראשונה שלו, מושג החיידק מתרחק ככל שנוכל לדמיין שבני אדם עושים מחשבים, מושגים כמו טלאי. המונח "טלאי" הגיע מיצירה של סרט קלטת שהודבק מעל חור בכרטיס אגרוף. אבל כל העניין של זה הוא שהמונח "ניפוי באגים" יצא מהמושג הזה של מציאת באג במכונה פיזית.ומאז, השתמשנו במינוח הזה סביב הניסיון להתמודד עם בעיות, או לא כל כך כמו נושאי קידוד בתוכנה שלא מורכבת, אלא כתוכנית שאינה פועלת היטב. ובמיוחד לא תוארו רק כדי למצוא דברים כמו לולאות בלתי נגמרות שפשוט הולכות לשום מקום.

אבל יש לנו גם תסריט, וחשבתי שעיד הכניס כמה שקופיות מצחיקות לפני שנכנסתי למעט יותר פירוט. הנה הקריקטורה הקלאסית, שנקראת XKCD באינטרנט, ולקריקטוריסט יש כמה השקפות די מצחיקות על העולם. וזה על ילד שנקרא "שולחנות בובי קטנים" וכביכול הוריו כינו את הילד הצעיר הזה רוברט); טפטף לוח תלמידים; - והקוראים לו, ומעין "היי, זה בית הספר לבנים שלך סובל מבעיות מחשב", וההורה עונה, "הו יקירי, הוא שבר משהו?" והמורה אומרת, "נו, בצורה מסוימת ", והמורה שואלת," האם באמת שמנת את בנך רוברט); הטפטף שולחן סטודנטים; -? "וההורה אומר," אה כן, טבלאות בובי הקטנות שאנחנו קוראים לו. "בכל מקרה, הם ממשיכים לומר שהם איבדו עכשיו את רישומי הסטודנטים של השנה, אני מקווה שאתה שמח. והתשובה היא, "ובכן, עליך לנקות ולחטא את תשומות מסד הנתונים שלך." ואני משתמש בה פעמים רבות בכדי לדבר על כמה מהבעיות שיש לנו במציאת דברים בקוד, שלעתים קרובות הקוד אינו מסתכל גם על הנתונים. .

עוד אחד מצחיק, אני לא יודע אם זה אמיתי או לא - אני חושד שזה זיוף - אבל שוב, זה גם נוגע לעצם המצחיקה שלי. מישהו מחליף את לוחית הרישוי בחזית מכוניתם, לאמירה דומה שגורמת למאגרי מידע לצנוח מצלמות מהירות וכדומה שתופסת את לוחיות הרישוי של המכוניות. ואני תמיד מתייחס לזה ככזה שאני בספק אם כל מתכנת שצפה להיט וריצה של הקוד שלהם על ידי רכב מנועי בפועל, אך מעולם לא מזלזל בזה - כוחו של חנון כועס.

(צחוק)

אבל זה מוביל אותי לנקודת המפתח שלי, אני מניח, וזה היה פעם שיכולנו לבצע ניפוי ופרופיל של קוד כתמות תמות בלבד. אבל אני מאוד רואה את התפיסה שהזמן הזה עבר, ובאופן אנקדוטלי מניסיוני, הראשון שלי - וזה נורא מזדיין אותי, אני בטוח; רובין אתה מוזמן לעורר לי כיף על זה - אבל מבחינה היסטורית אני בא מרקע בגיל 14 משוטט בסוף העיר, ודופק על דלת מרכז נתונים בשם "דאטה קום" בניו זילנד ושואל אם יכולתי להרוויח דמי כיס בבית הספר על ידי החזרת האוטובוס המנוח הביתה, כ -25 ק"מ של נסיעה לכל יום, על ידי הכנסת נייר, קלטות בכונני קלטת ופשוט להיות מנהל כללי. ובאופן מוזר הם כן נתנו לי עבודה. אבל עם הזמן הצלחתי להכניס את עצמי לאיוש ולמצוא את המתכנתים והבנתי שאני אוהב קידוד ועברתי את התהליך של הפעלת תסריטים ומשרות אצווה, שבסופו של יום היא עדיין קוד. צריך לכתוב סקריפטים ומשרות אצווה שנראות כמו תוכניות מיני ואז לעבור את כל התהליך של ישיבה על קוד כתיבה 3270 בטרמינל ביד.

לאמיתו של דבר, החוויה הראשונה שלי הייתה בטרמינל teletype, שהיה למעשה פיסי בן 132 עמודים. בעיקרו של דבר, חשוב על מכונת כתיבה ותיקה מאוד עם נייר שגלל דרכה, מכיוון שלא היה להם צינור CRT. וקוד איתור ניפוי בנושא זה היה עניין מאוד לא טריוויאלי, אז נטית לכתוב את כל הקוד שלך ביד ואז להתנהג כמו קלדנית, עושה כמיטב יכולתך לא לגרום לטעויות להתגנב, כי זה מאוד מתסכל שיש לך לדעת עורך השורות האחת כדי לעבור לשורה מסוימת ואז לקו ואז להקליד אותו שוב. אבל פעם, ככה כתבנו קוד וככה התקלנו, והגענו לנו מאוד מאוד טובים. ולמעשה, זה אילץ אותנו להשתמש בטכניקות תכנות טובות מאוד, מכיוון שזו הייתה טרחה אמיתית לתקן את זה. אבל המסע עבר אז - והיו מכירים את כל זה - זה עבר מחוויית המסוף 3270 בעולמי, לציוד דיגיטלי VT220 שם יכולתם לראות דברים על המסך, אבל שוב, אתם פשוט עושים את אותו הדבר שעשיתם על קלטת הנייר מעין פורמט ed רק על CRT, אבל הצלחת למחוק ביתר קלות ולא היה לך את הצליל "dit dit dit dit".

ואז אתה יודע, מסופי Wyse - כמו Wyse 150, ככל הנראה הממשק האהוב עליי למחשב אי פעם - ואז למחשב האישי ואז למק, ואז בימינו GUI ותעודות זיהוי מודרניות מבוססות אינטרנט. וטווח של תוכניות דרך זה, תכנות באחד ומרכיב ו- PILOT ולוגו ו- Lisp ו- Fortran ו- Pascal ושפות שעשויות לגרום לאנשים להתכווץ. אבל אלה שפות שאילצו אותך לכתוב קוד טוב; הם לא נתנו לך לצאת עם שיטות רע. C, C ++, Java, Ruby, Python - ואנחנו מתקדמים יותר באותו שלב תכנות, אנו מקבלים יותר דמויות סקריפט, אנו מתקרבים יותר ויותר לשפת שאילתות מובנות ולשפות כמו PHP שבעצם משמשות להפעיל SQL. הנקודה לספר לכם, כי מתוך הרקע שלי, לימדתי את עצמי במובנים רבים ואלו שעזרו לי ללמוד, לימדו אותי שיטות תכנות טובות מאוד ושיטות טובות מאוד סביב עיצוב ותהליכים כדי לוודא שלא הכנסתי באגי. קוד.

שיטות תכנות בימינו, דברים כמו למשל שפת שאילתה מובנית, SQL, שפת שאילתה מאוד חזקה ופשוטה. אבל אנחנו הפכנו את זה לשפת תכנות ואני לא באמת מאמין ש- SQL תוכננה אי פעם להיות שפת תכנות מודרנית, אבל אנחנו סקרנו אותה כדי להיות כזו. וזה מציג חבורה שלמה של סוגיות, הגורם כשאנחנו חושבים על זה משתי נקודות מבט: מנקודת מבט קידוד ומנקודת מבט של DBA. זה קל מאוד להגיע ולהכניס באגים לדברים כמו סתם טכניקות תכנות גרועות, מאמץ עצלני בכתיבת קוד, חוסר ניסיון, מציצת המחמד הקלאסית שיש לי למשל עם אנשי SQL שקופצים בגוגל ומחפשים משהו ומוצאים אתר זה קיבלתי דוגמא וביצע העתקה והדבקה של הקוד הקיים. ואז משכפל קידוד רע, רשלנות רפואית והכניסו אותה לייצור, כי זה קורה רק כדי לתת להם את התוצאות שהם רוצים. יש לך אתגרים אחרים, למשל, בימים אלה כולם מיהרו לעבר זה, מה שאנחנו מכנים את המירוץ לאפס: לנסות לעשות הכל כל כך זול וכל כך מהיר, שיש לנו תרחיש בו לא העסיקנו עובדים בשכר נמוך. ואני לא מתכוון לזה בצורה לא מגונה, אבל לא שכרתי מומחים לכל עבודה אפשרית. פעם היה קשור למחשבים מדע טילים; זה היה מעורב בדברים שהשתלבו והיו מאוד רועשים, או נכנסו לחלל או שהמהנדסים היו גברים ונשים מוכשרים מאוד שעשו תארים והיו להם חינוך קפדני שמנע מהם לעשות דברים מטורפים.

בימינו, אנשים רבים נכנסו לפיתוח ועיצוב ומסד נתונים, אשר לא היו בעלי ניסיון של שנים, והיה להם בהכרח אותה הכשרה או תמיכה. וכך אתה מסתיים בתרחיש של רק המומחה לחובבים לעומת מסורתיים. ויש קו מפורסם, אני לא ממש זוכר מי יצר את הצעת המחיר, השורה עוברת, "אם אתה חושב שהיקרה שלה לשכור מומחה שיעשה עבודה, חכה עד שתעסיק כמה חובבים שיוצרים בעיה ואתה צריך לנקות את זה. "וכך ל- SQL יש את הבעיה הזו, והקל מאוד מאוד ללמוד, קל מאוד לשימוש. אבל זו לא בעיניי שפת תכנות מושלמת. זה קל מאוד לעשות דברים כמו לעשות כוכב נבחר מכל מקום ולמשוך את כל זה לשפת תכנות שתהיה לך יותר נוח כמו PHP ורובי או פייתון, ולהשתמש בשפת התכנות שאתה מכיר באופן טבעי, כדי לעשות את המניפולציה של הנתונים, במקום לבצע שאילתה מורכבת יותר ב- SQL. ואנחנו רואים זאת הרבה, ואז אנשים תוהים מדוע מאגר המידע פועל לאט; זה בגלל שמיליון אנשים מנסים לקנות כרטיס מהמערכת הכרטיסים המקוונים, שם הוא עושה כוכב נבחר מכל מקום.

עכשיו, זו דוגמא ממש קיצונית, אבל אתה מקבל את הנקודה מכל זה. לכן, כדי פשוט לאגרוף את הנקודה הזו הביתה, הנה דוגמא שאני סוחב הרבה. אני אוהד גדול של מתמטיקה, אני אוהב תורת כאוס, אני אוהב את ערכות המנדלברוט. בצד ימין ישנו גרסה של סט מנדלברוט, שאותו בטוח הייתי מכיר. ובצד שמאל יש חתיכת SQL שלמעשה הופכת את זה. עכשיו, בכל פעם שאני מניח את זה למסך איפשהו, אני שומע את זה "אוי אלוהים, מישהו הציג את סדרת מנדלברוט עם SQL, אתה רציני? זה מטורף! "ובכן, כל הנקודה בזה היא להמחיש את מה שרק התארתי שם, וזה כן, למעשה אתה יכול לתכנת כמעט כל דבר ב- SQL; זוהי שפת תכנות מודרנית מאוד מפותחת, עוצמתית. כאשר במקור זו הייתה שפת שאילתה, היא נועדה רק להעלות נתונים. אז עכשיו יש לנו מבנים מורכבים מאוד ויש לנו נהלים מאוחסנים, יש לנו מתודולוגיית תכנות המיושמת על שפה ולכן זה מאוד קל לתרגול תכנות לקוי, חוסר ניסיון, קוד לחתוך והדבקה, צוות עם שכר נמוך שמנסה להיות עובדים עם שכר גבוה, אנשים מעמידים פנים שהם מכירים, אבל הם צריכים ללמוד בעבודה.

מגוון שלם של דברים שבהם פרופיל קוד ומה שאנחנו מתייחסים אליו כאל באגים, שהוא לא כל כך מוצא באגים שמונעים מהתוכניות לעבוד, אלא באגים שפשוט פוגעים במערכת וקוד מובנה בצורה לא טובה. כשאתה מסתכל על המסך הזה עכשיו, ואתה חושב, זה בדיוק, סוג החמוד שלו ואתה חושב, "וואו, איזה גרפיקה נהדרת, אני אוהב לנהל את זה." אבל דמיין את זה שרץ על איזה היגיון עסקי. זה נראה די מסודר, אבל זה מדבר תיאוריית כאוס מתמטית המוצגת בצורה גרפית, אבל כשאתה חושב על מה אפשר להשתמש בה בהיגיון עסקי כלשהו, ​​אתה מקבל את התמונה מהר מאוד. וכדי להמחיש זאת באמת - וסליחה שהצבעים הופכים, זה אמור להיות רקע שחור וירוק להיות מסך ירוק, אבל אתה עדיין יכול לקרוא את זה.

הלכתי ובדקתי מבט מהיר על דוגמא למה שאתה יכול לעשות אם אתה ממש משוגע ולא היה לך ניסיון כלשהו ובא מרקע שונה של תכנות והשתמשתי כמו C ++ ב- SQL, כדי להמחיש את הנקודה שלי, לפני אני מוסר לאורח המלומד שלנו מ- IDERA. זוהי שאילתה מובנית שנכתבת כמו C ++, אך היא מקודדת ב- SQL. והיא למעשה מבצעת, אבל היא מבוצעת על פני תקופה של שלוש עד חמש דקות. וזה מושך לכאורה שורה אחת של נתונים ממסדי נתונים מרובים, מצטרפים מרובים.

שוב, כל העניין של זה הוא שאם אין לך את הכלים הנכונים, אם אין לך את הפלטפורמות והסביבות הנכונות כדי שתוכל לתפוס את הדברים האלה, והם נכנסים לייצור, ואז יש לך 100,000 איש שפוגעים במערכת כל פעם יום, שעה או דקה, מהר מאוד אתה מסתיים בחוויה של צ'רנוביל, שם הברזל הגדול מתחיל להתמוסס ולקבור את עצמו לליבת כדור הארץ, מכיוון שאותו פיסת קוד לעולם לא צריכה להיכנס לייצור. המערכות שלך והכלי שלך, סליחה, צריכות לאסוף את זה לפני שהיא תעבור לכל מקום ליד - אפילו בתהליך הבדיקה, אפילו באמצעות UAT ושילוב מערכות, יש להרים ולהאיר את פיסת הקוד ולהביא מישהו בצד באומרו, "תראה, זה קוד ממש יפה, אבל מאפשר לקבל DBA שיעזור לך לבנות את השאילתה המובנית כראוי, כי בכנות, זה פשוט מגעיל." וכתובות האתר שם, אתה יכול ללכת להסתכל - זה מכונה " שאילתת SQL המורכבת ביותר שכתבת אי פעם. כי תאמינו לי, שאמנם אוספים, זה אכן פועל. ואם אתה חותך ומדביק את זה ופשוט לועג למסד הנתונים, זה די מה שצריך לצפות בו; אם יש לך כלים לצפייה במסד הנתונים, פשוט נסה להתמוסס במשך תקופה של שלוש עד חמש דקות, לחזור מהי שורה אחת של.

אם כן, לסיכום, עם זה בחשבון, כל הרקע שלי בקידוד לימד אותי שאפשר לתת לאנשים אקדח ואם הם לא נזהרים הם יורים בעצמם ברגל; החוכמה היא להראות להם היכן נמצא מנגנון הבטיחות. עם הכלים הנכונים והתוכנה הנכונה בהישג ידך, לאחר שתבצע את הקידוד, אתה יכול לבדוק את הקוד שלך, אתה יכול למצוא בעיות על ידי פרופיל הקוד, אתה יכול למצוא באגים לא מכוונים ביעילות שהם בעיות ביצועים, וכפי שאמרתי קודם לכן , פעם אתה יכול לעשות את זה כשהוא מסתכל על מסך ירוק. אתה לא יכול יותר; יש מאות אלפי שורות קוד, יש עשרות אלפי אפליקציות שנפרסות, ישנם מיליוני מאגרי מידע במקרים מסוימים, ואפילו בני אדם סופר לא יכולים לעשות זאת עוד ביד. אתה פשוט ממש זקוק לתוכנה הנכונה והכלים הנכונים בהישג ידך ואתה זקוק שהצוות ישתמש בכלים אלה, כך שתוכל למצוא את הבעיות הללו ולהתייחס אליהם במהירות רבה מאוד לפני שתגיע לעניין, ואילו דר. רובין בלור הדגיש, או שהדברים הופכים להיות הרת אסון, והדברים מתפוצצים, או שכיחות יותר, הם פשוט מתחילים לעלות לך הרבה דולרים והרבה זמן ומאמץ ולהרוס את המור והדברים, כשהם לא יכולים להבין מדוע דברים דורשים הרבה זמן לרוץ.

ועם זאת בחשבון, אני אעביר למסור לאורח שלי ואני מצפה לשמוע כיצד הם פתרו את הבעיה הזו. ובמיוחד ההדגמה שלדעתי עמדה לקבל. אריק, אני אעבור שוב.

אריק קוואנה: אוקיי, ברט, קח את זה משם.

ברט סקלזו: אוקיי תודה. ברט סקאלזו כאן מ- IDERA, אני מנהל המוצר של כלי מסד הנתונים שלנו. ואני הולך לדבר על ניפוי באגים. אני חושב שאחד הדברים החשובים ביותר שרובין אמר קודם - ועצם האמת הוא שביצוע באגים הוא מכביד ולא טריוויאלי, וכשאתה הולך למאגרי מאגרי נתונים זה סדר גודל אפילו יותר מכביד ולא טריוויאלי - כך, היה ציטוט חשוב.

בסדר. רציתי להתחיל עם היסטוריית תכנות, כי הרבה פעמים אני רואה אנשים שלא מבצעים ניפוי באגים, הם לא משתמשים בבאגים, הם פשוט מתכנתים בכל שפה שהם משתמשים בה, והרבה פעמים הם יגידו לי, "ובכן, הדברים האלה עם באגים הם חדשים, ואנחנו עדיין לא התחלנו להשתמש בזה. "ולכן מה שאני עושה זה אני מראה להם את תרשים ציר הזמן הזה, סוג של טרום היסטוריה, זיקנה, ימי הביניים, סוג של לומר איפה היינו מונחים של שפות תכנות. והיו לנו שפות ישנות מאוד החל משנת 1951 עם קוד הרכבה, ו- Lisp ו- FACT ו- COBOL. ואז אנחנו נכנסים לקבוצה הבאה, פסקלים ו- Cs ואז הקבוצה הבאה, ה- C ++, ונראה איפה הסימן הזה נמצא - סימן השאלה הזה בערך סביב 1978 עד אולי 1980. איפשהו בטווח הזה היה לנו באגים שעמדו לרשותנו, וכדי לומר, "היי, אני לא משתמש בבאגים, גורם לזה אחד הדברים החדשים האלה", בטח התחלת לתכנת, אתה יודע, בשנות החמישים, בגלל שזו הדרך היחידה שאתה יכול לקבל בטענה זו.

עכשיו הדבר האחר שמצחיק בתרשים הזה הוא דץ רק הגיב על גרייס הופר, אני באמת הכרתי את גרייס, אז זה סוג של מצחיק. ואז הדבר השני שצחקתי עליו הוא שהוא דיבר על טלטיפים ואני יושב שם והולך, "בנאדם, זו הייתה הקפיצה הכי גדולה שעברנו אי פעם בפריון, כשהלכנו מכרטיסים לטלטיפים, זו הייתה הקפיצה הגדולה ביותר אי פעם." , ואני תיכנתתי בכל השפות כאן, כולל SNOBOL, שאיש לא שמע עליהם מעולם, זה היה CDC, Control Data Corporation, אז אני מניח שאני מזדקן קצת יותר מדי לתעשייה הזו.

דז בלנשפילד: התכוונתי לומר, היית מזדקן אותנו שם נורא.

ברט סקלזו: כן, אני אומר לך, אני מרגיש כמו סבא סימפסון. אז אני מסתכל על ניפוי באגים ודרכים שונות לבצע ניפוי באגים. אתה יכול לדבר על מה שכולנו חושבים כמסורתית להיכנס לבאגים ולעבור דרך קוד. אך גם אנשים יתאימו לקוד שלהם; זה המקום בו אתה מכניס הצהרות לקוד שלך ואולי אתה מפיק קובץ פלט, קובץ עקבות או משהו, וכך אתה מכשיר את הקוד שלך. הייתי מחשיב את זה כניפוי באגים, זה קצת יותר קשה, כדרך לעשות את זה, אבל זה נחשב. אבל גם, יש לנו את ההצהרה המפורסמת: אתה צופה ואנשים מכניסים אמירות, ואני באמת ראיתי כלי איפה - וכלי מסד הנתונים שלו. איפה שאתה לא יודע להשתמש בבאגים, אתה לוחץ על כפתור והוא ידבק הצהרות לאורך הקוד שלך עבורך ואז כשסיימת לחץ על לחצן אחר וזה מפשיט אותן. כי ככה הרבה אנשים מתלבטים.

והסיבה שאנו מבצעים ניפוי באגים כפולים: ראשית, עלינו למצוא דברים שהופכים את הקוד שלנו לבלתי יעיל. במילים אחרות, בדרך כלל פירוש הדבר שיש טעות בהיגיון או שהחמצנו דרישה עסקית, אך מה שכן, הקוד אינו יעיל; זה לא עושה את מה שציפינו שהוא יעשה. בפעם השנייה שאנו מבצעים ניפוי באגים, זה בשביל היעילות וזה יכול להיות טעות הגיונית, אבל מה שכן, עשיתי את הדבר הנכון, זה פשוט לא חוזר די מהר. עכשיו, אני מעלה את הטענה הזו משום שפרופילרים ככל הנראה היו טובים יותר עבור התרחיש השני ההוא והיו מדברים על שגיאות באגים וגם על פרופילים. בנוסף, יש מושג זה של ניפוי באגים מרחוק; זה חשוב מכיוון שהרבה פעמים אם אתה יושב על המחשב האישי שלך ואתה משתמש בבאגים, שפוגע במסד נתונים בו הקוד מבוצע בפועל במסד הנתונים, אתה באמת עושה מה שנקרא ניפוי באגים מרוחק. אתה אולי לא מבין זאת, אבל זה מה שקורה. ואז, זה מאוד מקובל עם שגיאות הבאגים האלה שיש נקודות שבירה, צפייה בנקודות, צעד וחוצה ועוד כמה דברים נפוצים אחרים, שאותם אני אראה לרגע את אלה שנמצאים על מסך המסך.

כעת, פרופיל: אתה יכול לעשות פרופיל בכמה דרכים שונות. יש אנשים שיגידו שעומס העבודה לוכד ומשחק מחדש במקום בו הוא לוכד הכל, וזה נחשב לפרופיל. הניסיון שלי היה יותר טוב יותר אם נעשה את הדגימה. אין שום סיבה לתפוס כל הצהרה בודדת, מכיוון שהצהרות מסוימות עלולות לרוץ כל כך מהר שלא אכפת לך, מה שאתה באמת מנסה לראות זה, ובכן, אלו הם אלה שממשיכים להופיע שוב ושוב, כי הם רצים יותר מדי זמן . כך שלעתים פרופיל יכול להיות פירושו דגימה ולא הפעלת כל העסק. ובדרך כלל, תקבל איזשהו פלט שתוכל להשתמש בו, עכשיו שיכול להיות חזותי בסביבת פיתוח IDE, שם זה עשוי לתת לך כמו היסטוגרמה של הביצועים של שורות הקוד השונות, אבל זה יכול גם עדיין להיות שהוא מייצר קובץ עקבות.

פרופילים הופיעו לראשונה בשנת 1979. כך, אלה קיימים כבר זמן רב. נהדר למציאת צריכת משאבים, או בעיות ביצועים, במילים אחרות הדבר היעיל. באופן כללי, זה נפרד ונבדל מהבאגים, אם כי עבדתי עם באגים שעושים את שניהם בו זמנית. ובעוד שפרופילרים לדעתי הם המעניינים יותר מבין שני הכלים, אם אני מרגיש שלא מספיק אנשים מתלבטים, אז בהחלט לא מספיק אנשים מפרופילים, מכיוון שאחד מתוך עשרה באגים יתעד, נראה. וחבל, כי הפרופילציה באמת יכולה לעשות את ההבדל העצום. עכשיו, שפות מסד נתונים, כפי שדיברנו עליה קודם, קיבלת SQL - ואנחנו סוגים אילצו את יתד העגול לחור המרובע כאן ואילצו אותו להפוך לשפת תכנות - ואורקל.זה PL / SQL - זה SQL בשפה פרוצדורלית - ושרת SQL, ה- Transact-SQL, ה- SQL-99 שלו, ה- SQL / PSM שלו - עבור, אני חושב, המודול המאוחסן של נוהל. Postgres נותן לו שם אחר, DB2 ועוד שם אחר, Informix, אבל העניין הוא שכולם אילצו מבנים מסוג 3GL; במילים אחרות, לולאות FOR, בהצהרות משתנות וכל שאר הדברים הזרים ל- SQL הם כעת חלק מ- SQL בשפות אלה. וכך, אתה צריך להיות מסוגל לבצע באגים ב- PL / SQL או ב- Transact-SQL בדיוק כמו שהיית עושה תוכנית Basic Basic.

עכשיו, אובייקטים בבסיסי נתונים, זה חשוב מכיוון שאנשים יגידו, "ובכן, אילו דברים יש לי לבצע ניפוי בבסיס נתונים?" והתשובה היא, ובכן, כל מה שתוכל לאחסן במאגר כקוד - אם אני עושה T- SQL, או PL / SQL - ו- Im אוגרים אובייקטים בבסיס הנתונים, ככל הנראה הליך מאוחסן או פונקציה מאוחסנת. אבל יש גם מפעילים: טריגר דומה לאופן הליך מאוחסן, אך הוא יורה על אירוע כלשהו. כעת, יש אנשים שמפעילים את הטריגר שלהם יכניסו שורת קוד אחת ויתקשרו לנוהל מאוחסן כך שישמרו על כל הקוד והנהלים המאוחסנים שלהם, אך אותה תפיסה: עדיין הטריגר שלה יכול להיות מה שיוזם את כל העניין. ואז בתור אורקל, יש להם משהו שנקרא חבילה, שהיא דומה לספריה אם תרצו. אתה שם 50 או 100 נהלים מאוחסנים בקבוצה אחת, המכונה חבילה, כך שהיא דומה לספריה. אז, הנה הבאגים בדרך הישנה; זהו למעשה כלי שממש ייכנס ויתקע עבורך את כל הצהרות הבאגים הללו בקוד שלך. אז בכל מקום שאתה רואה חסימת ניפוי, אל תסיר, את הבאגים האוטומטיים מתחילים ומעקב, אלה היו תקועים בכלי כלשהו. והשורות מחוץ לזה, שהיא מיעוט הקוד, ובכן, זוהי שיטת הבאגים שאינה ידנית.

והסיבה שאני מעלה את זה היא שאם אתה מנסה לעשות זאת ביד, אתה אכן מקליד קוד ניפוי נוסף בכדי להכניס את כל ההצהרות האלה מכפי שאתה בקוד. אז למרות שזה יכול לעבוד, ואף על פי שהוא טוב יותר מכלום, זוהי דרך קשה מאוד להתחקות, במיוחד מכיוון, מה אם ייקח 10 שעות עד שהדבר הזה יפעל, והיכן שיש לו בעיה הוא בשורה שלוש? אם הייתי עושה סשן באגים אינטראקטיבי, הייתי יודע בשורה שלוש - חמש דקות לתוכו - היי, יש כאן בעיה, אני יכול לפרוש. אבל עם זה, אני חייבת לחכות שזה יעבור, כל הדרך להשלמתו ואז הייתי צריך להסתכל על איזה קובץ עקבות שכנראה יש בו את כל ההצהרות האלה, ולנסות למצוא את המחט בערימת השחת. שוב, זה טוב מכלום, אבל זו לא תהיה הדרך הטובה ביותר לעבוד. כעת, כך נראה הקובץ שהגיע מהשקופית הקודמת; במילים אחרות, ניהלתי את התוכנית, ופשוט קיבלו חבורה של הצהרות בקובץ העקבות הזה, ואולי לא אוכל לחלוף דרך זה ולמצוא את מה שאני צריך למצוא. אז שוב, אני לא כל כך בטוח שזו הדרך בה תרצו לעבוד.

עכשיו, באגים אינטראקטיביים - ואם השתמשת במשהו כמו Visual Studio כדי לכתוב תוכניות, או Eclipse, היו לך באגים באינסטגרם והשתמשת בהם בשפות אחרות שלך - פשוט לא חשבת להשתמש בהם כאן עם בסיס הנתונים שלך. ויש כלים שם בחוץ, כמו DB Artisan שלנו ו- SQL המהיר שלנו, זה SQL Rapid כאן, שיש להם באגים, ואתה יכול לראות בצד שמאל, יש לי נוהל מאוחסן שנקרא "בדוק כפילויות". בעיקרון, זה פשוט הולך להסתכל ולראות אם יש לי מספר שורות בטבלה עם אותה כותרת סרט. אז, מסד הנתונים מיועד לסרטים. ואתה יכול לראות בצד ימין, בשליש העליון, יש לי את קוד המקור שלי באמצע, יש לי מה שנקרא משתני השעון שלי ומגשי ערימת השיחות שלי, ואז בתחתית יש לי כמה פלטים. ומה שחשוב כאן הוא, אם אתה מסתכל על החץ האדום הראשון, אם אני מעביר עכבר מעל משתנה, אני באמת יכול לראות איזה ערך יש במשתנה באותו רגע בזמן, כשאני עובר דרך הקוד. וזה ממש שימושי, ואז אוכל לעבור שורה אחת בכל פעם בקוד, אני לא צריך להגיד ביצוע, יכולתי לומר שלב שורה, תן לי להסתכל מה קרה, לדרוך שורה אחרת, תן לי לראות מה קרה, אני עושה זאת במסד הנתונים. ולמרות שאני יושב על SQL המהיר במחשב האישי שלי ובסיס הנתונים שלי נמצא בענן, אני עדיין יכול לבצע ניפוי ניווט מרוחק זה ולראות אותו ולשלוט עליו מכאן, ולבצע באגים בדיוק כמו שהייתי עושה בכל שפה אחרת.

עכשיו, החץ הבא שם - אתה יכול לראות את החץ הדומה למצביע שמצביע ימינה, לכיוון אותו פלט DBMS, זה איפה שהסמן שלי נמצא כרגע - אז במילים אחרות, אני צעדתי וזה איפה אני באותו הרגע. אז אם אני אומר, "צעד שוב," אני הולך לשורה הבאה. עכשיו ממש מתחת לזה תראו את הנקודה האדומה. ובכן, זו נקודת שבירה, שאומרת "היי, אני לא רוצה לעבור על הקווים האלה." אם אני רק רוצה לקפוץ מעל הכל ולהגיע למקום הנקודה האדומה ההיא, אני יכול ללחוץ על כפתור ההפעלה וזה גם יפעל מכאן ל הסוף, או לנקודת שבירה, אם נקבעים נקודות נקודה, ואז זה ייפסק ויאפשר לי לעשות את הצעדים שוב. והסיבה שזה כל חשוב וחזק היא, מכיוון שכשאני עושה את כל זה, מה שקורה באמצע ואפילו בתחתית - אבל הכי חשוב באמצע - ישתנה ואני יכול לראות את הערכים מהמשתנים שלי, אני יכול ראה את עקבות ערימת השיחות שלי, אתה יודע, וכך כל המידע הזה מוצג שם כשעובב בקוד, כך שאני באמת יכול לראות ולהרגיש ולקבל הבנה לגבי הנעשה ואיך הקוד פועל בזמן ביצוע. . ובדרך כלל אני יכול למצוא בעיה, אם יש בעיה, או אם אני מספיק טוב לתפוס אותה.

אוקיי, עכשיו אני הולך לדבר על פרופיל, ובמקרה זה, זה פרופיל שאני יכול לראות באמצעות debugger. זוכר שאמרתי שלפעמים הם נפרדים ולפעמים הם יכולים להיות ביחד? במקרה זה, ושוב, אני נמצא ב- SQL מהיר, ואני יכול לראות שולי זה, בצד שמאל, לצד מספרי השורות. ומה שכן, זה מספר השניות או המיקרו-שניות שלקח כדי לבצע כל שורת קוד, ואני יכול לראות את זה בבירור, כל הזמן שלי מבלה בלולאה FOR זו שבה אני בוחר כל מהטבלה. וכך, שוחרי המתרחש בתוך לולאת FOR זו כנראה משהו שאני צריך להסתכל עליו, ואם אוכל לשפר אותו, הוא ישלם דיבידנד. אני לא מתכוון להשיג שיפורים על ידי עבודה על קווים כאלה שיש להם 0.90 או 0.86; אין הרבה זמן לבזבז שם. עכשיו, במקרה זה, ושוב, אני ב- SQL מהיר, אתה רואה כיצד אוכל לבצע פרופילים מעורבבים עם ניפוי הבאגים שלי. עכשיו, מה נחמד ש- Rapid SQL מאפשר גם לך לעשות את זה בדרך ההפוכה. SQL מהיר מאפשר לך לומר, "אתה יודע מה? אני לא רוצה להיות באגים, אני רק רוצה להריץ את זה ואז אני רוצה להסתכל בצורה גרפית או חזותית על אותו סוג מידע. "

ותוכלו לראות כי אני כבר לא נמצא בבאגים והוא מנהל את התוכנית ואחרי שהביצוע מסתיים, זה נותן לי תרשימים לספר לי דברים כדי שאוכל לראות שיש לי הצהרה אחת שנראית כאילו היא תופסת את רוב העוגה תרשים ואם אני מסתכל אני רואה על הרשת ההיא לכיוון התחתון, שורה 23, שוב מופיע הלולאה FOR: הוא לוקח את הזמן הכי הרבה, הוא למעשה האדום הכהה שמלעיס את כל תרשים העוגה. וכך, זוהי דרך נוספת לביצוע פרופילים. אנו קוראים לזה "אנליסט קוד" בכלי שלנו. אבל זה בעצם רק פרופיל שנפרד מהבאגים. יש אנשים שאוהבים לעשות את זה בדרך הראשונה, יש אנשים שאוהבים לעשות את זה בדרך השנייה.

מדוע אנו מבצעים ניפוי באגים ופרופיל? זה לא בגלל שאנחנו רוצים לכתוב את הקוד הגדול ביותר בעולמות ולקבל העלאת שכר - זו אולי הסיבה שלנו, אבל זו לא באמת הסיבה שאתה עושה את זה - הבטחת לעסק שתעשה משהו נכון, שהתכנית שלך תהיה אפקטיבית. בשביל זה תשתמש בבאגים. בנוסף, משתמשי קצה עסקיים; הם לא מאוד סבלניים: הם רוצים תוצאות עוד לפני שהם לוחצים על המקש. היו אמורים לקרוא את דעתם ולעשות הכל באופן מיידי. במילים אחרות, זה צריך להיות יעיל. וכך, בשביל זה היינו משתמשים בפרופילר. עכשיו, בלי הכלים האלה, אני באמת מאמין שאתה הבחור הזה בחליפה העסקית עם החץ והקשת ואתה יורה לעבר המטרה ואתה מכוסה עיניים. כי איך תמצאו כיצד תוכנית מבצעת רק על ידי הסתכלות על קוד סטטי וכיצד תוכלו להבין איזו שורה היא היכן היא באמת תבלה הכי הרבה זמן בביצוע, שוב, רק על ידי התבוננות בקוד סטטי? סקירת קוד עשויה או לא עשויה להופיע בחלק מהדברים האלה, אך אין שום ערובה לכך שסקירת קוד תמצא את כולם. באמצעות שגיאות באגים ופרופילים, אתה אמור להיות מסוגל למצוא את כל הבאגים האלה.

אוקיי, אני פשוט אעשה כאן הדגמה מהירה ממש. זה לא הכוונה שלי לדחוף את המוצר, אני רק רוצה להראות לך איך נראה באגי בגלל הרבה פעמים שאנשים יגידו, "מעולם לא ראיתי אחד כזה לפני כן." וזה נראה יפה בשקופיות הצמדה של המסך, אבל מה האם זה נראה כשהוא בתנועה? אז כאן, על המסך שלי אני מפעיל את המוצר שלנו DB Artisan; יש לנו גם באגים שם. ה- DB Artisan מיועד יותר ל- DBA, ה- SQL המהיר הוא יותר עבור המפתחים, אבל ראיתי מפתחים המשתמשים ב- DB Artisan, וראיתי DBAs המשתמשים ב- Rapid. אז אל תתפסו עם המוצר. וכאן, יש לי אפשרות לבצע ניפוי באגים, אך לפני שאני משיק את הבאג, אני הולך לחלץ את הקוד הזה כדי שתוכל לראות איך נראה הקוד לפני שאני מתחיל להריץ אותו. אז הנה בדיוק אותו קוד שהיה בתמונת המסך, זו הסימון שלי לשכפול. ואני רוצה לבצע ניפוי באגים, אז אני לוחץ על באגים. ועכשיו, זה לוקח רגע ואתה אומר, "ובכן, למה זה לוקח רגע?" זכור ניפוי ניפוי מרוחק: הבאגינג מתרחש למעשה בשרת מסד הנתונים שלי, ולא במחשב האישי שלי. אז זה היה צריך לעבור וליצור שם סשן, ליצור דבר באגים מרוחק, לחבר את ההפעלה שלי לאותו סשן ניפוי מרוחק ולהקים ערוץ תקשורת.

אז, הנה החץ שלי, הוא שם למעלה, על ידי שורה אחת, זה איפה אני נמצא בקוד. ואם אני לוחץ על הסמל השלישי שם, שהוא צעד פנימה, תראה את החץ הזה זז, ואם אני ממשיך ללחוץ עליו, תראה אותו ממשיך לנוע. עכשיו, אם רציתי לרדת עד הלולאה הזו FOR, מכיוון שאני יודע איפה הבעיה, אני יכול להגדיר נקודת שבירה. חשבתי שקבעתי את זה. אוי לירות, היה לי אחד ממקשי לכידת המסך שלי ממופים לאותו מפתח כמו הבאגים, זה מה שגורם לבלבול. אוקיי, אז פשוט קבעתי שם נקודת שבירה באופן ידני, אז עכשיו במקום לעשות צעד, צעד, צעד, צעד עד שאגיע לשם, למעשה אני יכול פשוט לומר, "קדימה, תריץ את הדבר הזה," וזה ייפסק. שימו לב שזה העביר אותי כל הדרך למקום בו נמצאת נקודת השבירה, אז אני עכשיו בעניין של הפעלת לולאה זו, אני יכול לראות למה כל המשתנים שלי מוגדרים, וזה לא הפתעה, כיוון שאתחלתי את כולם ל אפס. ועכשיו, אני יכול להיכנס ללולאה הזו ולהתחיל להסתכל על המתרחש בתוך הלולאה הזו.

אז עכשיו זה יבצע ספירה נבחרת מהשכירות שלי ואני יכול לעבור על הבחור הזה ולהסתכל, היי שתיים, שתיים גדולות יותר מאחת, כך שהיא בטח תעשה את הקטע הבא של הקוד הזה. במילים אחרות, הוא מצא משהו. אני רק הולך להמשיך ולתת לזה לרוץ. אני לא רוצה לעבור את הכל כאן; מה שאני רוצה להראות לך זה כשנגמר שגיאות באגים, זה מסיים בדיוק כמו תוכנית רגילה. איבתי את נקודת הפריצה, אז כשאמרתי ריצה, זה פשוט חזר לנקודת הפסקה הבאה. אני נותן לו לרוץ עד הסוף, הגורם למה שאני רוצה שתראה זה ש- debugger לא משנה את אופן הפעולה של התוכנית: כשסיימה אותה, עלי להשיג את אותן תוצאות אם הייתי מפעיל אותה לא בתוך באגים.

ועם זה, אני הולך להשעות את ההדגמה ולחזור אחורה כי אנו רוצים לוודא שיש לנו זמן לשאלות ותשובות. וכך, אפתח את זה לשאלות ותשובות.

אריק קוואנה: בסדר, רובין, אולי שאלה ממך ואז זוג מדז?

רובין בלור: כן, בטוח, אני כמובן מרתק את זה. Ive עבד עם דברים כאלה, אבל מעולם לא עבדתי עם דבר כזה במאגר. אתה יכול לתת לי מושג לגבי מה אנשים משתמשים בפרופילר? מכיוון שכך הם מסתכלים - כי אני מניח שהם - הם מסתכלים על בעיות ביצועים, האם זה יעזור לכם להבחין בין מתי מסד נתונים לוקח זמן וכאשר קוד לוקח זמן?

ברט סקלזו: אתה יודע, זו שאלה פנטסטית. נניח שאני עובד ב- Visual Basic, ואני, בתוך ה- Visual Basic Im שלי, מתקשר Transact-SQL או PL / SQL. תן לי לעשות את PL / SQL, מכיוון שאורקל לא משחקת טוב תמיד עם הכלים של מיקרוסופט. יתכן שאני מפרסם את הקוד Visual Basic שלי, והפרופיל שם יכול לומר, "היי, התקשרתי לנוהל המאוחסן הזה וזה לקח זמן רב מדי." אבל אז אני יכול להיכנס לפרוצדורה המאוחסנת ואני יכול לעשות פרופיל מסד נתונים על האחסון נוהל ולומר, "אוקיי, מתוך 100 ההצהרות שנמצאות כאן, הנה החמישה שגרמו לבעיה. וכך, ייתכן שתצטרך לעשות צוות תגיות, שם עליך להשתמש במספר פרופילים.

הרעיון הוא שאם אי פעם תספר לך שבעיית הביצועים נמצאת במאגר המידע שלך, פרופיל מסד נתונים עשוי לעזור לך למצוא את המחט בערימת השחת עליה אמירות הן בעצם אלה בהן יש לך בעיה. אני אומר לך עוד דבר שהגיע עם הפרופיל: אם יש לך פיסת קוד שמתקשרת מיליון פעם, אבל זה לוקח רק מיקרו-שנייה כל אחת ממיליון הפעמים, אבל זה נקרא מיליון פעם, מה היה הפרופילר מראה , הדבר הזה רץ ליחידות הזמן הרבות האלה. וכך, למרות שהקוד עשוי להיות יעיל מאוד, אתה יכול להסתכל ולהגיד, "או, אתה קורא את זה לחתיכת קוד זו לעתים קרובות מדי. אולי עלינו לקרוא לזה רק לעתים תכופות, ולא בכל פעם שאנחנו מעבדים רשומה, "או משהו כזה. וכך למעשה תוכלו למצוא היכן יש קוד יעיל שנקרא פשוט לעיתים קרובות מדי, וזו בעצם בעיית ביצועים.

רובין בלור: כן, זה נפלא. מעולם לא עשיתי זאת. אתה מבין, כמובן, כאשר היו לי בעיות במאגר נתונים זה היה כאילו הייתי בדרך זו או אחרת עוסק במאגר מידע או מתמודד עם קוד; מעולם לא יכולתי להתמודד עם שניהם במקביל. אבל שם, שוב, לא עשיתי זאת - מעולם לא הייתי מעורב בבניית יישומים שבהם שמרנו נהלים, אז אני מניח שאף פעם לא נתקלתי בבעיות שהיו משגעות אותי, הרעיון שתפלג את הקוד בין מסד נתונים ותוכנית. אבל כן, עשו הכל - אני מניח שהתשובות יהיו כן, אבל זה חלק מפעילות צוות פיתוח, כשאתה בדרך כזו או אחרת מנסה לתקן משהו שנשבר, או אולי מנסה להפגיש אפליקציה חדשה. אך האם כל זה מותאם עם כל שאר המרכיבים שהייתי מצפה בסביבה? האם אוכל לצפות שאוכל לגזור זאת יחד עם כל חבילות הבדיקה שלי וכל הדברים האחרים שהייתי עושה ועם דברים של ניהול פרויקטים שלי, האם זה איך כל הסרטונים האלה יחד?

ברט סקלזו: כן, זה יכול להיות חלק מכל תהליך מובנה לעשות מאמצי תכנות או פיתוח. וזה מצחיק, בשבוע שעבר היה לי לקוח שבונה אפליקציה לאינטרנט, והמאגר שלהם היה קטן, מבחינה היסטורית, ולכן העובדה שהם לא היו מתכנתים טובים מעולם לא פגעה בהם. ובכן, בסיס הנתונים שלהם גדל עם השנים, ועכשיו זה לוקח 20 שניות בדף אינטרנט, בין כשאומרים "התחבר לי ותן לי נתונים לראות" וכאשר המסך יופיע, וכך עכשיו בעיית ביצועים. והם ידעו שהבעיה לא הייתה באף אחד מהג'אווה שלהם או באחד מאותם מקומות אחרים. אבל היו להם אלפי נהלים מאוחסנים ולכן הם נאלצו להתחיל לפרסם את הנהלים המאוחסנים כדי לגלות מדוע לוקח דף אינטרנט זה 20 שניות לעלות? ולמעשה גילינו שיש להן קרטזית שהצטרפה לאחת מההצהרות הנבחרות שלה ולא ידעה זאת.

רובין בלור: וואו.

ברט סקלזו: אבל מישהו אמר לי פעם אחת, "נו איך הם יכולים להצטרף לקרטזיאן ולא לדעת זאת?" וזה יישמע ממש נורא; לפעמים מתכנת שלא כל כך נוח עם SQL יעשה משהו כמו לתת לי הצטרפות קרטזית, אבל אז רק יחזיר לי את הרשומה הראשונה, אז אני יודע שיש לי משהו, ואני רק צריך את הראשון. וכך, הם לא מבינים שהם פשוט החזירו מיליארד רשומות או שהם מסתכלים על מיליארד רשומות בגלל שהם קיבלו את זה שהם התעניינו בו.

רובין בלור: וואו, אני יודע, כך קוראים - ובכן, זה מה שקרה דז ', מבחינת אנשים שלא בדיוק מיומנים כמו שהם צריכים להיות, אתה יודע. אם אתה מתכנת, עליך לדעת מה ההשלכות של הוצאת פקודה כלשהי. כלומר, באמת, אין שום תירוץ לרמת הטיפשות הזו. אני גם מניח שאתה, בדרך זו או אחרת, סתם שפה אגנוסטית באשר לזה, מכיוון שכל זה מתמקד בצד הנתונים. האם אני צודק בזה? האם זה אותו דבר, מה שאתה משתמש בצד הקידוד?

ברט סקלזו: בהחלט, אתה יכול לעשות זאת בפורטרן או C או C ++. למעשה, בכמה יוניקסים תוכלו אפילו לעשות זאת עבור שפות התסריט שלהם; הם למעשה מספקים את אותם כלים. ואז אני רוצה לחזור שנייה אחורה על מה שאמרת ללא תירוץ. אני הולך לתת למתכנתים הפסקה אחת, כי אני לא אוהב לזרוק מתכנתים מתחת לאוטובוס. אבל הבעיה היא באמת הסביבה האקדמית מכיוון שכשאתה לומד להיות מתכנת, לימדת חשיבה רשמית בזמן. לא מלמדים אותך חשיבה ערכית, וזה מה ששפת שאילתות מובנות, או SQL עובדת עם סטים; זו הסיבה שיש לנו את האיחוד, את הצומת ומפעיל המינוס. וזה קשה מאוד לפעמים לאדם שלעולם לא חשב במונחים של סטים, להיגמל, להרפות מעיבוד מתעד בכל פעם ולעבוד עם סטים.

רובין בלור: כן, אני איתך על זה. כלומר, אני מבין עכשיו שזה נושא חינוך; אני חושב שזה נושא חינוכי לחלוטין, אני חושב שזה טבעי שהתכנתים יחשבו בצורה פרוצדורלית. ו- SQL אינו פרוצדוראלי, הצהרתו. אתה בעצם רק אומר, "זה מה שאני רוצה ולא אכפת לי איך תעשה את זה," אתה יודע? ואילו בשפות תכנות, לעיתים קרובות הגעת לשרוולים שלך והפכת למטה לפרטים הקטנים של אפילו לנהל את הספירות, בזמן שאתה עושה לולאה. יד חולה על -

ברט סקלזו: לא. אוקיי, המשך.

כן, התכוונתי להגיד שהצגת דוגמא אחת נוספת לכך שפרופילר יהיה טוב לתפוס את זה, מהסוג שקורה עם העיבוד הרשומי הזה בזמן. לפעמים, מתכנת שהוא טוב בלוגיקה של שיא בזמן, לא מצליח להבין כיצד לבצע תוכנית SQL. ובכן, נניח שהוא עושה שני לולאות FOR ובעצם משתלב, אבל הוא עושה זאת בצד הלקוח. אז, הוא עושה את אותו האפקט של הצטרפות, אבל הוא עושה זאת בעצמו, והפרופיל יתפוס את זה, כי סביר להניח שבסופו של דבר הייתם מבלים זמן רב יותר בביצוע ההצטרפות באופן ידני מאשר לתת לשרת מסד הנתונים לעשות זאת עבורכם.

רובין בלור: כן, זה יהיה אסון. זאת אומרת, אתה פשוט מתפוצץ. תחבולות תמיד גרועות.

בכל מקרה, אני אעבור לדצמבר; אני בטוח שהס יש כמה שאלות מעניינות.

דז בלנשפילד: תודה, כן. אני הולך להצטרף אליך לא לזרוק מתכנתים מתחת לאוטובוס. כלומר, ביליתי יותר מדי שנים בחיי בהיותי קידוד בעצמי, בכל רמה, אתה יודע, אם זה כמו שאמרת, כשהייתי יושב בשורת הפקודה של מכונת יוניקס, ובמקרים מסוימים, אפילו הייתי מעורב ב כמה יציאות שונות של יוניקס מפלטפורמת חומרה אחת לאחרת. ואתה יכול לדמיין את האתגרים שהיו לנו שם. אבל המציאות היא שכרטיס הכרטיס היוצא מהכלא לכל קידוד ותסריטאי בעולם. זה מדע טילים, פשוטו כמשמעו, לכתוב ממש חזק כל פעם, כל הזמן, הוא מדע טילים. וסיפורים מפורסמים של אנשים כמו דניס ריצ'י ובריאן קרנהן עובדים על פיסת קוד באופן עצמאי ואז פונים לצ'אט של סקירת קוד על קפה ומגלה שהם כתבו בדיוק את אותה פיסת קוד, באותה תוכנית בדיוק, בדיוק באותה תוכנית באותה צורה. והם עשו את זה ב- C. אבל רמת התכנות הפוריסטית הזו קיימת לעיתים רחוקות מאוד.

העובדה היא שבאופן יומיומי יש רק 24 שעות ביממה, שבעה ימים בשבוע, ואנחנו רק צריכים לעשות דברים. וכך, כשמדובר לא רק במתכנתים מסורתיים, ב- DBA, ובקודרים, ותסריטים, וסיסדמין, מנהלי רשת, ואנשי אבטחה, וכל מה שמגיע עד לצד הנתונים של האזרח בימינו; אנחנו שומעים, כולם פשוט מנסים לעשות את העבודה שלהם. ולכן אני חושבת שההשתלטות הגדולה מכל העניין הזה היא שאהבתי את ההדגמה שלך ואהבתי את הנסיעות שהשארת אותנו שם, רק לפני רגע, כשדיברתי עם רובין על העובדה שיש לזה פרט - אולי לא כל כך הרבה גומחה - אך מרחב רחב שהוא חל עליו, בכל הקשור לתיקון קוד ו- SQL ומסדי נתונים. אבל ממש התרגשתי לשמוע שאתה אומר שאתה יכול להציב את זה בתסריט של מעטפת ולמצוא כמה בעיות, כי אתה יודע, בימינו ובימינו היו תמיד עובדים במחיר הנמוך ביותר של הכל.

הסיבה שאתה יכול לקנות חולצה של 6 $ איפשהו, היא מכיוון שמישהו בנה מערכת זולה מספיק כדי לייצר ולשלוח בפועל ולספק ולשלוח לוגיסטית ולמכור וקמעוני ולקחת תשלומים מקוונים כדי להשיג את החולצה של 6 $. וזה לא קורה אם קיבלת מאנשים 400,000 דולר לשנה כדי לכתוב קוד בצורה המושלמת; ההתפתחות כולה. אז הנקודה הזו, אני מניח שאחת השאלות שאני באמת אוהבת אותך פשוט תתן לנו קצת יותר תובנה, היא מה רוחב הרוחב והטווח של סוג האנשים שאתה רואה כרגע שמפרסים כלים מסוג זה כדי לפרופיל קוד ולהסתכל לבעיות ביצועים? בתחילה, מבחינה היסטורית, מאיפה הם מגיעים? האם הם היו בתי ההנדסה הגדולים? ואז, קדימה, האם זה נכון, האם אני צודק במחשבה שיותר ויותר חברות מיישמות את הכלי הזה, או את הכלים האלה, כדי לנסות לעזור לקודרים, את מי שהם יודעים שעושים רק דברים כדי לסיים את העבודה. ולהוציא אותו מהדלת? ולפעמים האם אנו זקוקים לכרטיס יציאה מהכלא? האם אני צודק במחשבה כי מבחינה היסטורית היה לנו מוקד ופיתוח הנדסי יותר? זה שעכשיו, מקבלים גישה פחות או יותר, כמו שרובין אמר, גישה אקדמית, ועכשיו הקוד שמלמד את עצמו או גזור והדבק, או סתם בונים דברים? והאם זה תואם את סוג האנשים שלוקחים את המוצר עכשיו?

ברט סקלזו: כן בדיוק. ואני אתן לך דוגמא מאוד ספציפית, אנחנו רק רוצים לעשות את העבודה, כי אנשי העסקים לא רוצים שלמות. זה כמו משחק שחמט ממוחשב: משחק השחמט לא מחפש את התשובה המושלמת; היא מחפשת תשובה שהיא מספיק טובה בפרק זמן סביר, כך שככה אנו מתכנתים. אבל מה שאני מוצא עכשיו זה, רוב האנשים במקום לומר שהם רוצים פרופיל כחלק מבדיקת היחידות שלהם - כך הייתי עושה זאת, כי אני לא רואה את זה בזבוז זמן - מה שקורה זה עכשיו שנעשה מאוחר יותר, לפעמים, במהלך בדיקות אינטגרציה או בדיקת מתח, אם היה מזל. אבל ברוב הפעמים החלק שלה בהסלמה, שם משהו עבר לייצור, הוא רץ למשך זמן מה, אולי אפילו רץ במשך שנים, ועכשיו זה לא עובד טוב, ועכשיו פרופיל אותו היטב. ונראה שזה התרחיש השכיח יותר כעת.

דז בלנשפילד: כן, ואני חושב שהמונח "חוב טכני" הוא כנראה יותר מכיר; אני מכיר את רובין ואני בהחלט. אני חושב שבימינו, במיוחד בגישות זריזות לפיתוח ובניית מערכות, מבחינתי, הרעיון של חוב טכני הוא דבר אמיתי מאוד, ואנחנו למעשה אחראים לכך בפרויקטים. אני יודע, כלומר, יש לנו פרוייקטים משלנו כמו עדשת המדיה ואחרים, שם קרה לנו קידוד על בסיס יומיומי, ודברים שונים ברחבי קבוצת בלור. ובכל פעם שבנו משהו, אנחנו מסתכלים על זה, אני מסתכל על זה, ומתבונן תמיד מנקודת המבט של מה זה יעלה לי לתקן את זה כרגע, לעומת האם אני יכול פשוט להכניס אותו לפחית תביא אותו לשם ואז תראה אם ​​הדברים האלה ישברו. ולרשת את החוב הטכני הזה שאני יודע שאצטרך לחזור אחורה אחר כך ולתקן.

כלומר, עשיתי את זה בשבעת הימים האחרונים: כתבתי כמה כלים ותסריטים, כתבתי כמה קטעים משפת פייתון, ואני פרסתי אותה לקצה האחורי של מונגו, מוודא שהיא נחמדה ונקיה ובטוחה, אבל זה פשוט מקבל את השאילתה שאני צריך לעשות, בידיעה שאני צריך את הפונקציה הזו כדי לעבוד, כדי להגיע לפאזל הגדול יותר; זה הכאב האמיתי שלי. וכך אתם חבים את החוב הטכני הזה, ואני חושב שזה לא רק דבר מזדמן, אני חושב שזה חלק מה- DNA של ההתפתחות כעת. אנשים פשוט - לא בפירוש - הם פשוט מקבלים את החוב הטכני הוא סוג נושא רגיל של אופן פעולה, והם פשוט צריכים להיגרם אליו. זה המקום בו אתה נושא את החוב הטכני. ואני חושב שהדבר הנפלא עם מה שהראית לנו בהדגמה היה שאתה ממש יכול לפרופיל ולראות כמה זמן לוקח משהו לרוץ. וזה כנראה אחד הדברים האהובים עלי. כלומר, בעצם בניתי כלים לתכנות - היינו בונים כלים בסד ולקס וב- Orc כדי להריץ את הקוד שלנו ולראות איפה לולאות, לפני שכלים כאלה היו זמינים - וכשבנית קוד ללכת ולסקור את הקוד שלך , אתה טוב מאוד בכך שלא תצטרך לבדוק את הקוד שלך. אבל זה לא המקרה עכשיו. עם זאת, האם יש פלח שוק מסוים שתופס את זה יותר מכל אחר? רואים כמו המיסה -

ברט סקלזו: אה כן, יש לי - אני הולך לצייר אנלוגיה בשבילך ולהראות לך שאינם מתכנתים עושים את זה כל הזמן. הסיבה שאם אי פעם אני מלמד שיעורים או מפגשים של באגים ופרופילים, אני שואל אנשים, "בסדר, כמה אנשים כאן נכנסים למיקרוסופט וורד בכוונה לעולם לא משתמשים בבודק האיות?" ואף אחד לא שם את היד, כי לצורך כתיבת מסמכים, כולנו יודעים שאנחנו יכולים לטעות באנגלית, ולכן כולם משתמשים בבודק האיות. ואמרתי, "נו, איך זה כשאתה כותב ב- IDE שלך כמו Visual Basic, אתה לא משתמש בבאגים? זה אותו דבר, זה כמו בודק איות. "

דז בלנשפילד: כן, למעשה, זו אנלוגיה נהדרת. לא באמת חשבתי עליי, אני חייב להודות שאני באמת עושה משהו דומה עם כמה כלים שאני משתמש בהם. למעשה, אחת, ODF, האהוב עלי ביותר על Eclipse הוא פשוט לחתוך ולהדביק קוד שם וללכת לחפש דברים שפשוט מדגישים מייד ולהבין שעשיתי שגיאת הקלדה באיזו שיחת כיתה. וגם, אבל עכשיו זה מעניין עם הכלי כזה אתה יכול לעשות את זה בזמן אמת לעומת לחזור ולהסתכל עליו אחר כך, וזה די נחמד לתפוס אותו מראש. אבל כן, זו אנלוגיה נהדרת של פשוט להכניס מעבד תמלילים, לגרום לשיחת השכמה מעניינת שסתם תבינו שעשיתם שגיאת הקלדה או אפילו שגיאת דקדוק, נכון?

ברט סקלזו: בדיוק.

דז בלנשפילד: אז, האם אתה רואה יותר Uptick משמע אני משער, כלומר, השאלה הסופית ממני, לפני שאזרוק לשאלות ותשובות שלנו אולי, למשתתפים שלנו. אם אתה מתכוון לתת המלצה כלשהי סביב הגישה לעשות זאת - אם אני מניח שזה רטורי - האם זה המקרה שאתה נכנס מוקדם ומיישם את זה ככל שאתה מתפתח, לפני שאתה מתפתח? או שזה המקרה שלרוב אתה מתחיל לבנות, להתקדם, לבנות משהו ואז להיכנס לפרופיל אחר כך? אני חושד שזה המקרה של כניסה מוקדמת וודא שהקודים שלך נקיים מראש. או שזה מקרה שעליהם לשקול את החלק הזה של הפריסה שלהם?

ברט סקלזו: באופן אידיאלי, הם היו עושים זאת מראש, אך מכיוון שכולם נמצאים בעולם ההמולה, שם הם פשוט צריכים לעשות דברים, הם נוטים שלא לעשות זאת עד שהם יתקלו בבעיית ביצועים שהם לא יכולים לפתור על ידי הוספת עוד מעבדים וזיכרון. למחשב וירטואלי.

דז בלנשפילד: כן. אז בעצם הזכרת משהו מעניין, אם אוכל מהר? הזכרת קודם שאפשר להפעיל את זה מכל מקום, ויכול לדבר עם מסד הנתונים בקצה האחורי. אז זה נוח עם סוג התפיסה הבימודלית עליה אנו מדברים כעת, של ענן מקומי / מחוץ להנחה, גם למראה הדברים, בסוף היום, אם זה יכול לדבר עם הקצה האחורי ולראות הקוד, לא באמת אכפת לו, נכון?

ברט סקלזו: בדיוק, כן, אתה יכול להריץ את זה בענן.

דז בלנשפילד: מעולה, כי אני חושב שזה לאן הולך העולם האמיץ החדש שלנו. אז אריק. אני הולך לחזור אליך עכשיו ולראות שיש לנו כאן כמה שאלות ואני רוצה שהנוכחים שלנו עדיין ישארו איתנו, למרות שעברנו את השעה.

אריק קוואנה: כן, יש כמה אנשים שם בחוץ, רק אעיר תגובה מהירה: ברט, אני חושב שהמטאפורה, האנלוגיה שאתה נותן לשימוש בבדיקת איות היא מבריקה באמת. זה ראוי לבלוג או שניים, למען האמת, מכיוון שזו דרך טובה למסגר את המשמעות של מה שאתה עושה, וכמה הוא בעל ערך, ואיך זה אמור להיות השיטה הטובה ביותר להשתמש בבאגים על בסיס קבוע, נכון? אני בטוח שאתה מקבל כמה ראשים מהנהנים כשאתה משליך את זה, נכון?

ברט סקלזו: בהחלט, הגורם שמה שאני אומר להם הוא: "מדוע אני מבצע בדיקת איות על המסמכים שלי? אני לא רוצה להתבייש מטעויות כתיב מטופשות. "ובכן, הם לא רוצים להתבייש מטעויות קידוד מטופשות!

אריק קוואנה: ימין. אכן כן. ובכן, חברים, עברנו כאן שעה וחמש דקות, תודה גדולה לכולכם שם בזמנכם ותשומת ליבכם. אנו מבצעים ארכיון של כל שיחות האינטרנט הללו, אל תהסס לחזור בכל עת ולבדוק אותם. המקום הטוב ביותר למצוא קישורים אלה הוא ככל הנראה techopedia.com, אז הוסיפו זאת לרשימה זו ממש כאן.

ועם זה, התכוונו להיפרד מכם, אנשים. שוב עבודה נהדרת, ברט, תודה לחברינו מ- IDERA. טוב לדבר איתך בפעם הבאה, טוב לדבר איתך בשבוע הבא, למעשה. שמור על עצמך! ביי ביי.