[Powered by Google Translate] [סמינר] [פיתוח אינטרנט: מרעיון ליישום] [בן קון] [בילי Janitsch] [אוניברסיטת הרווארד] [זה CS50] [CS50.TV] [בילי] היי, אני בילי וזה בן. >> [בן] היי. אנחנו הולכים לדבר על התפתחות אינטרנט היום. [Webdev] [בילי Janitsch ובן קון] קצת עלינו ראשון. בן הוא סוג של עורפי הבחור. הוא עושה דברים עובדים. ואז אני נכנסתי ולהפוך אותם יפה. אני מעורב במידה רבה יותר עם סוג עיצוב פריסה החזיתי של דברים, ובן, לעומת זאת, יודע מה הוא עושה ולכן הוא עובד על דברים עורפיים. יחד עשינו כמה דברים. לדוגמא, בשנה שעברה עבדנו על Gimblium שהוא אולפן פיתוח משחקים מקוון. זה היה פרויקט הגמר שלנו לכיתה, ומאז שעשינו בהרווארד כיתה אשר מהווה מסגרת לגלישה באינטרנט וקורסי קניות באוניברסיטת הרווארד. 

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

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

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

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

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

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

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

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

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

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

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

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

יש גם כמה דברים מתקדמים יותר שאתה יכול לעשות אם אתה מחפש לעשות יישום האינטרנט שלך תוספת מדהימה. אתה יכול לעשות - יש לו את המפרט של HTML5 החדש הרבה דברים מפוארים שאתה יכול לעשות. אחסון מקומי - שהיא תוכל לשמור את הנתונים בדפדפן - ולא שיש לחזור ולעיין בשרת לכל דבר, אתה יכול לשמור על חלק ממנו על הלקוח ושגם מאפשר לאנשים - במקרים מסוימים זה יכול אפילו לתת לך להשתמש במצב לא מקוון בדף האינטרנט. יש דבר כזה שנקרא WebSockets שהם סוג של תקשורת ברשת שונה שבו ולא רק שאתה עושה בקשה אחת, אתה מקבל תגובה ושתסיים, אתה ממשיך לפתוח חיבור לשרת ואז אתה יכול לעשות דברים כמו עדכונים בזמן אמת. לכן, אם אתה מנסה להפוך את יישום צ'אט, אתה יכול להשתמש WebSockets כדי לתקשר הלוך ושוב, כך שלא היית צריך לשמור המבקש, "אה, שרת, האם מישהו שלח לי בצ'אט?" כל 10 שניות או משהו כזה. יש גם תכונת HTML5 מעניינת שבו אתה יכול לגרום לזה להיראות כמו URL של הדף משתנה מבלי בעצם לטעון אותו מחדש. אתה יכול להשתמש בכפתורים אחורה וקדימה בלי לעשות חבורה של בקשות רשת. דברים כאלה הוא באמת שימושיים במונחים של מה שהופך את מהיר, אלא גם לעבוד כמו Web App צריך. 

יש גם הדבר הזה שנקרא CoffeeScript. CoffeeScript הוא שפה שונה, למעשה, כי הידור עד JavaScript. היית לכתוב את כל הקוד שלך בCoffeeScript, ולאחר מכן תפעיל מהדר זו, וזה יורק את קובץ JavaScript שניתן לכלול בדף האינטרנט שלך. הסיבה שCoffeeScript הוא נחמד, משום שהיא מסלקת הרבה מקרים מוזרים שיש בו JavaScript שווה שווים, ושווה שווים לעשות דברים שונים, או רוצה - יש לה תחביר נחמד יותר להתמודדות עם מערכים ופונקציות. זהו קטע קטן של CoffeeScript שמייצר רשימה של כל הריבועים מ10 ^ 2 ^ 1 2 בסדר הפוך. כפי שניתן לראות, CoffeeScript לעתים קרובות מאפשר לך לבטא בקו 1 מה היו לוקח 5 שורות של JavaScript. זה יכול לעשות דברים הרבה יותר קל. זה קצת ללמוד תחביר חדש בהתחלה, אבל זה בהחלט יגרום לך יותר פרודוקטיביים בטווח הארוך. 

ניתן גם להשתמש בשפות אחרות על השרת מאשר PHP - שפות כמו Ruby, Python, או יש אפילו פרויקט שנקרא node.js שיאפשר לך להשתמש ב-JavaScript בשרת. אישית, אני ממש ממש שונא את PHP. אני פשוט לא נהניתי לעבוד איתו. אם אתה גם חושב שזה cluge נורא של שפה, אז אתה יכול להשתמש באחד מהפורמטים האלה. באופן כללי, אם אתה רוצה לעשות משהו ואתה לא ממש יודע איך היית עושה את זה, רק לחפש באינטרנט. יש טונות של משאבים במיוחד על - StackOverflow הוא אחד גדול. זה האתר הזה שבו מתכנתים לשאול זה את זה שאלות. ייתכן שתיתקל בזה אם היית נתקל בבעיות בסטי הבעיה CS50. ויש טונות של ספריות לעושים כמעט כל דבר שאתה רוצה. אם אתה רוצה לעשות משהו ואתה לא יודע איך לעשות את זה, אל תניחו שזה בלתי אפשרי. רק תסתכל מסביב ואתה עלול למצוא כמה משאבים טובים. 

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

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

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

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

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

הכלי הבא הוא JavaScript ו-jQuery שבן דיבר קצת על, אבל אני אביא קצת רחוק יותר אליו. JavaScript, כמו שאתה כבר עובד עם זה קצת, או לפחות ראית את זה בהרצאה, הוא סוג של דרך דינמית לעשות דברים ב-HTML. HTML, כמו שאתה יודע, הוא סטטי, ולכן ברגע שיש לך HTML אתה לא יכול לשנות אותה. אבל JavaScript, במובנים מסוימים, הוא דרך כדי להיות מסוגל לשנות את ה-HTML. אז אתה יכול לעשות את זה, וזה נהדר, אבל JavaScript באמת כאב לעבוד איתו. זה כל כך ארוך וקהה ולעשות אפילו את הדברים הפשוטים ביותר דורש המון שורות של JavaScript. אז, jQuery היא בעצם ספריית JavaScript שמפשטת את כל זה. זה אומר, בסדר, אם אתה רוצה יש לי קופסא מרובעת באה מהשמאל ונמוג לתוך הדף כך שזה באמצע, ב-JavaScript שייקח - אני לא יודע, מאה קווים לעשות, וזה יהיה כאב, ולך תצא מזה לשנוא את הכל על תכנות אינטרנט. JQuery אתה בעצם יש את האלמנט-dot-לדעוך ב, או משהו כזה. פונקציות אז, מאוד, מאוד פשוטות שיאפשר לך לעשות כל מיני אנימציות מגניבים ודברים מהסוג הזה. הדבר השני ש2 אלה הם באמת טובים להוא פשוט עושה דברים דינמיים עם האתר. אז, לא רק שיש דף HTML שלך - אשר מציג כמה נתונים, אבל לא ממש לעשות שום דבר - JavaScript ו jQuery ייאפשרו לך לחצנים שאתה יכול ללחוץ על, ואתה יכול לגרור אלמנטים ואותם מחדש את הסדר ולמיין אותם, ויש להם אלמנטים חדשים הוספה או הסרה. אתה יכול להוסיף-Delete, דברים מהסוג הזה. אז, jQuery עושה טונות של דברים מגניבים. וVipul הוא בעצם נותן סמינר על זה היום, אני מאמין, בשעה 5, כך שאם אתה יכול להישאר בסביבה במשך כל כך הרבה זמן, שהיית - 5 או 4? ארבעה. סליחה. זה בעצם מייד אחרי זה, ולכן אני ממליץ נשאר לזה אם אתה יכול. JQuery היא סופר, סופר שימושי, ואתה תהיה מסוגל לעשות הרבה דברים ממש נחמדים עם זה עבור כמעט כל פרויקט פיתוח אינטרנט. 

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

דבר נוסף שאתה רוצה לנסות לעשות הוא, אם מישהו הולך להיכנס לאתר שלך ו -9 מתוך 10 פעמים לעשות פעולה, ו1 מתוך 10 פעמים לעשות פעולה ב ', אתה כנראה רוצה להתמקד הניסיון שלהם בפעולה א במילים אחרות, אתה רוצה לעשות את זה כמה מאוד, מאוד ברור לעשות א ' ואת מרכז קדמי צריך להיות - להיכנס לאתר, לראות אותו, הו, זה ממש שם. ואילו ב 'ברור שאתה רוצה שיהיה ברור, אבל אתה יכול לעזוב את זה קצת יותר ברקע. דוד נותן דוגמא טובה לכך בהרצאה, המהווה את מערכת בוסטון T. כשאתה הולך לבוסטון T ואתה רוצה לקנות כרטיס, יש לך להיכנס ל5 תפריטים לפני שאתה בעצם יכול לרכוש כרטיס לשווי 2 $, $ 2.50, אשר הוא עד כמה שנדרש כדי לרכב על הרכבת התחתית בכיוון אחד. זו בעיה, משום שרוב האנשים שנסעו ברכבת התחתית כנראה רק רוצה ללכת למקום אחד, לקנות את הכרטיס שלהם, לקבל באופן מיידי. זה לא הגיוני שהם צריכים לעבור הרבה תפריטים שונים כדי להגיע לשם. חוויית משתמש טובה יותר תהיה כפתור מהיר בעמוד הראשון שפשוט אומר, 'לקנות כרטיס בכיוון אחד', וזה היה לשים בכל התקן ערכי ברירת מחדל, ואז אם מישהו רוצה לקנות כרטיס שונה מזה, עדיין, כמובן, יש להם את האפשרות, אבל יש לך אופטימיזציה עבור המקרה הנפוץ השימוש בו הוא באמת חשוב. אתה יכול לראות דוגמאות לכך בפייסבוק, נכון? אם אתה הולך לפייסבוק ואתה רוצה לכתוב סטטוס, זה נכון בחלקו העליון וזה מה שלעתים קרובות אתה רוצה לעשות. ברגע שאתה נכנסת לדף, אתה יכול לעשות את הדברים הנפוצים ביותר, כי אתה רוצה לעשות. אם אתה רוצה לעשות דברים קצת יותר מסובכים כמו, להגיד שאני רוצה ללכת לקיר של חבר שלי ולפרסם את תמונה על זה - שאני רוצה לעשות לעתים קרובות, אבל לא לעתים קרובות ככל שפרסום עדכוני סטטוס - ולכן במקרה זה, אני מקליד את שמם בתיבה בחלק העליון, לחץ על הפרופיל שלהם, ולאחר מכן, עדיין, זה נכון בחלקו העליון יש שאחרי שאני הגעתי לפרופיל שלהם. שוב, אני כבר מותאם בראש סדר עדיפויות של מקרים הנפוץ ביותר לשימוש. 

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

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

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

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

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

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

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

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

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

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

עוד דבר שימושי באמת שאני לא חושב שהוא התווה במידה רבה בCS50 אבל זה שווה להיכנס הוא בקרת גרסאות. הרעיון של בקרת גרסאות הוא כאשר אתה בעצם עוקב אחרי כל ההתקדמות שבצעת לכיוון האתר שלך ואם בכל נקודה שאתה מבין, אה, זה היה עובד לפני זמן מה, אבל זה לא עובד יותר, אתה יכול לחזור לגרסות קודמות ולראות מה השתנה מאז ודברים מהסוג הזה. הדרך העיקרית לעשות זאת היא עם גית, וGit הוא כל סוג זה של מערכת ש אני מאמין טומי MacWilliam נתן סמינר על שנה שעברה. אם אתה הולך לסמינרי CS50 ל2011, אתה יכול לראות את הסמינר שלו על זה. הרעיון של Git הוא בעצם שבמרווחים זמן קבועים שאתה עושה התחייבויות אלה שדרכים לומר האתר זה בגרסה די יציבה עכשיו כל כך אני אריזה אותו ושולח אותו לשרת, ואז אתה יכול ללכת לאותו שרת ומסתכלים על כל הגרסאות הקודמות של הקוד שלך ולראות איך זה התקדם וכל הסוג של חומר טוב. אז, זה בעצם אותו. ככל פיתוח אינטרנט, אנחנו שמחים להישאר בסביבה ולענות על כל שאלות ככל שהמצגת שלנו. זה מכיל. תודה. >> [בן] תודה. [מחיאות כפיים] 

צוות, למישהו יש [בילי] שאלות על דברים שאנחנו כבר כיסינו או דברים שאנחנו כבר לא מכוסים כי הם מקווים שהיינו לכסות? נשמח לענות עליהם. אף אחד? [חבר קהל] מה הם היתרונות וחסרונות של שימוש ברובה או באמצעות פייתון? [בן] השאלה הייתה, מה הם היתרונות וחסרונות של שימוש ברובה או פייתון במקום כמו PHP. היתרונות הם שרובי ופיתון הם שפות הרבה יותר טובים מאשר ה-PHP. לפחות לדעתי, ואני חושב בהרבה דעות של אנשים אחרים גם כן. הם נועדו יותר לעושים דברים מורכבים, ופחות לכביר יחד דפי אינטרנט ממש במהירות עם קצת תוכן דינמי. החסרונות הם שיש קצת - יש יותר מעקומה למידה כדי להגדיר אותם. כלומר, כמו ב-PHP, אתה יכול פשוט יש קובץ HTML ואתה כותב פחות מ, סימן שאלה, ולאחר מכן אתה כותב קצת קוד, ולאחר מכן אתה כותב סימן שאלה, גדול מ ', ולאחר מכן סיימת. בשפות אחרות כמו רובי או פייתון, אתה צריך לעבור קצת יותר עבודה כדי לקבל את הריצה האתר הראשונית. יש גם - לפחות זה היה אמור להיות במקרה - שיש יותר תיעוד זמין עבור PHP רק בגלל שיש יותר אנשים משתמשים בו. אני חושב שזה לא באותה המידה של בעיה יותר. אין ספק שתיעוד טוב מאוד על דברים כמו Ruby on Rails או Django לפייתון הוא שווה הערך. PHP היא אחת לכולם שכבר משתמש במשך שנים, ואתה יודע איך זה עובד. רובי ופייתון הם קצת פחות בוגרים. 

[חבר קהל] אם הייתם צריך לבחור בין אחד מהם ללמוד או להרים, מה אתה מעדיף? בכנות, אני חושב שזה תלוי באדם. אני מצטער. השאלה הייתה שהיית בוחר ללמוד ממישהו? אני מוצא פייתון הכי נחמד באופן אישי. יש הרבה אנשים ש-- עשיתי הפרויקט הראשון שלי באינטרנט dev בפייתון וג'נגו. יש הרבה אנשים שגם אוהבים את Ruby on Rails. כנראה יותר אנשים שמכירים את Ruby on Rails. בכנות, אני הייתי הולך רק עם מה שהאנשים סביבך יודעים כך שיש לך אנשים לשאול שאלות. 

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

[חבר קהל] אני פשוט נכנסתי ללמוד כיצד לבצע שאילתא כמה מסדי נתונים, ואני יודע SQL שלי הוא בכל המקום, אבל לאחרונה יש לי חשוף ל-- ואתה ציין את זה. אתה רואה JSON ומסדי נתונים הניתנים להרחבה. SQL שלי הוא עדיין בכל המקום. איך אתה רואה את זה קורה? האם יש הולך להיות נטייה גוברת להרחבה יותר (לא נשמע)? השאלה הייתה - אני חושב שיש הולך להיות מגמה של מסדי נתונים שאינם של SQL. לדוגמא, כמו MongoDB. אני חושב שזה בהחלט נכון. העצה שלי הייתה קשורה mySQL-בעיקר כאן רק בגלל mySQL הוא סטנדרטי. תעשייה אישית, אני מעדיף בהרבה מסדי נתונים שאין לי schemos כמו MongoDB שבו אין לך הבעיה של, הו, אני צריך להוסיף עמודה נוספת. אוי לי, כמו כל מה שעליי לעשות? זה מאוד קשה לעשות את זה על MySQL, אבל כאשר יש לך משהו כמו מונגו זה הרבה יותר נחמד. הדבר נחמד האחר על מונגו הוא שהרשומות שלך הן למעשה אובייקטים ב-JavaScript. אין שום סוג של צעד גיור שבו אתה צריך לקחת את שורות מסד נתונים אלה ולהפוך אותם לאובייקט JavaScript ולאחר מכן לשלוח אותם מעבר לגדר. אני חושב שדברים כאלה הולכים להיות מאוד, מאוד שימושיים עבור פיתוח אינטרנט מהיר בעתיד. 

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

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

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

אני חושב שזה על זה, אז שוב תודה שבאתם. אנחנו ממש נהנינו לדבר איתך חבר 'ה ומקווים שלמדת כמה דברים. [בן] אנחנו שמחים לדבר - אנחנו צריכים ללכת אבל אנחנו שמחים לדבר יותר מחוץ אם יש לך שאלה אחרת. שוב תודה. [מחיאות כפיים] [CS50.TV]