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

על ידי צוות Techopedia, 15 במרץ, 2017

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(צחוק)

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

לאמיתו של דבר, החוויה הראשונה שלי הייתה במסוף teletype, שהיה למעשה מדפסת פיזית של 132 עמודים. בעיקרו של דבר, חשוב על מכונת כתיבה ישנה מאוד עם נייר שגלל בה, כי לא היה להם צינור CRT. וקוד איתור ניפוי בנושא זה היה נושא מאוד לא טריוויאלי, ולכן נטית לכתוב את כל הקוד שלך ביד ואז להתנהג כמו קלדנית, עושה כמיטב יכולתך לא לגרום לטעויות להתגנב, כי זה מאוד מתסכל לדעת לספר עורך השורות האחת כדי לעבור לשורה מסוימת ואז להדפיס את השורה ואז להקליד אותה שוב. אבל פעם, ככה כתבנו קוד וככה ניפפפנו, והגענו לנו מאוד מאוד טובים. ולמעשה, זה אילץ אותנו להשתמש בטכניקות תכנות טובות מאוד, מכיוון שזו הייתה טרחה אמיתית לתקן את זה. אבל המסע אז עבר - וכולנו מכירים את זה - הוא עבר מחוויית המסוף 3270 בעולמי, לציוד דיגיטלי VT220 שם יכולתם לראות דברים על המסך, אבל שוב, אתם פשוט עושים את אותו הדבר עשית על קלטת הנייר מעין פורמט מודפס רק ב- 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 Server, זה Transact-SQL, זה SQL-99, זה SQL / PSM - עבור, אני חושב, זה מודול נוהל מאוחסן. Postgres נותן לו שם אחר, DB2 ועוד שם אחר, Informix, אבל העניין הוא שכולם אילצו מבנים מסוג 3GL; במילים אחרות, לולאות FOR, בהצהרות משתנות וכל שאר הדברים הזרים ל- SQL הם כעת חלק מ- SQL בשפות אלה. וכך, אתה צריך להיות מסוגל לבצע באגים ב- PL / SQL או ב- Transact-SQL בדיוק כמו שהיית עושה תוכנית Basic Basic.

עכשיו, אובייקטים של מסד נתונים, זה חשוב מכיוון שאנשים יגידו, "ובכן, אילו דברים יש לי לבצע באגים בבסיס נתונים? והתשובה היא, ובכן, כל מה שתוכל לאחסן במאגר כקוד - אם אני עושה T-SQL, או PL / SQL - ואני מאחסנת אובייקטים בבסיס הנתונים, זה כנראה נוהל או פונקציה מאוחסנת. אבל יש גם טריגרים: טריגר דומה לזה של הליך מאוחסן, אבל הוא יורה על אירוע כלשהו. כעת, יש אנשים שהטריגר שלהם יכניס שורת קוד אחת ויתקשר לפרוצדורה מאוחסנת כך שישמרו על כל הקוד והנהלים המאוחסנים שלהם, אבל זה אותו הרעיון: זה עדיין הטריגר יכול להיות מה שיוזם את כל העניין. ואז בתור אורקל, יש להם משהו שנקרא חבילה, שהיא דומה לספריה אם תרצו. אתה מכניס 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 לא משנה את התנהגות התוכנית: לאחר סיום הריצה, הייתי צריך להשיג את אותן תוצאות בדיוק אם הייתי מפעיל אותה לא בתוך באגים.

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

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

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

ברט סקלזו: אתה יודע, זו שאלה פנטסטית. בואו נגיד שאני עובד ב- Visual Basic ואני בתוך Visual Basic שלי אני אקרא 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 דולר לשנה כדי לכתוב קוד בצורה המושלמת; זה פשוט פיתוח שלם. לכן, נקודה זו, אני מניח שאחת השאלות שבאמת אשמח שתספקו לנו קצת יותר תובנות, היא מה רוחב הרוחב והטווח של סוג האנשים שאתם רואים כרגע שמפרסים כלים מסוג זה לפרופיל קוד ולחפש בעיות ביצועים? בתחילה, מבחינה היסטורית, מאיפה הם מגיעים? האם הם היו בתי ההנדסה הגדולים? ואז, קדימה, האם זה נכון, האם אני צודק במחשבה שיותר ויותר חברות מיישמות את הכלי הזה, או את הכלים האלה, כדי לנסות לעזור לקודרים, את מי שהם יודעים שעושים רק דברים כדי לסיים את העבודה. ולהוציא אותו מהדלת? ולפעמים האם אנו זקוקים לכרטיס יציאה מהכלא? האם אני צודק במחשבה כי מבחינה היסטורית היה לנו מוקד ופיתוח הנדסי יותר? שעכשיו, אנו מקבלים גישה פחות טובה, כמו שרובין אמרה, גישה אקדמית, ועכשיו זה קוד לימוד עצמי, או חתוך והדבקה, או סתם נבנים דברים? והאם זה תואם את סוג האנשים שלוקחים את המוצר עכשיו?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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