סיוון

כנס You Gotta Love Frontend – היום הראשון

לפני כשבוע התקיים כנס מתכנתי פרונט-אנד – You Gotta Love Frontend באולם הקאמרי בתל-אביב. על הכנס שמענו לפני כמה חודשים, ועל אף שרוב המרצים בו טרם פורסמו – מיהרנו להרשם. מהכרותנו עם חלק מהמארגנים הנחנו – הנחה שהצדיקה את עצמה, ובגדול – כי המרצים וההרצאות יהיו מהשורה הראשונה.

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

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

Douglas Crockford  | Upgrading the Web

על הדבר הכי עכשווי שקרוקפורד עובד עליו

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

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

קרוקפורד התחיל בכך שתיאר את האינטרנט כיום כמשהו שהתחיל בתור מערכת אחזור מסמכים מבוזרים פשוטה, והתפתח לשימוש באפליקציות שהולכות הרבה מעבר ליכולות ולכוונות ההתחלתיות של המערכת. אמנם, הצלחנו לגרום לזה לעבוד, אבל הדרכים בהן זה עובד הן מסובכות ושבירות מדי. הדבר שהכי מדאיג את קרוקפורד הוא האבטחה. האבטחה באינטרנט היא בעייתית – חלקים חיוניים של החיים שלנו נמצאים ברשת, והיא לא נועדה לזה, ולא יכולה לשמור עליהם כראוי. דוגמה טובה לזה היא סיסמאות: לא לכולם יש סיסמאות שונות לכל אתר, וגם קל מאד לפתות אנשים למסור את הסיסמאות (phishing, clickjacking). בכלל, פעם היו מעבירים סיסמאות ב-URL עצמו, מה שהוא מסוכן מאד כמובן. אבל אין פתרונות טובים יותר.
הוא עבר על הדברים הלא כ”כ טובים, לדעתו באינטרנט. למעשה, כמעט בכל דבר יסודי ומהותי לאינטרנט הוא הצליח להראות איפה החסרונות שלו. הבאתי כאן את עיקרי דבריו:

  • HTTP – שלושה חסרונות: הוא כלי של מפתח וערך (key-value); הוא עושה משא ומתן, כי הוא צריך לומר איזה פורמטים הוא מקבל (זכר לימים שבהם דפדפנים לא תמכו בכל פורמטי התמונות, אז היה על הדפדפנים לקבל מידע באיזה פורמט התמונה שהם ממעבירים, כדי שידעו אם הם יכולים להציג אותה); והכי גרוע זה שזה פרוטוקול של בקשה/מענה (request/response), מה שגורם לקפיאה בזמן שמחכים (לכן, למשל, לפעמים משתמשים בפתרונות של פתיחת מספר ערוצים, כדי  לאפשר פניה לשרת מתי שרוצים).
  • DNS – לא אמין
  • SSL – עד עצם היום הזה הוא עדיין לא עובד, עדיין מוצאים בו בעיות, למרות שהוא קיים 14 שנה. יש אוטוריטות בתחום, אבל אי אפשר לסמוך עליהם. מצד שני, הדפדפן שלנו סומך עליהם, וזה כמובן בעייתי.
  • HTML – קשה לכתיבה בגלל שהוא עושה דברים שהוא לא נועד לעשות. בגלל זה המציאו את markdown, אבל עדיין HTML הוא הכלי העיקרי לכתיבה באינטרנט, למרות הבעיות הרבות שיש בו. הבעיה העיקרית בו היא שהוא מעודד templating,  שיש בו 3 חסרונות, מתוכם אני זוכרת רק אחד, את הכי גרוע – הוא מאפשר XSS.
  • DOM – גרוע. למרות שיש שכבות שמאפשרות להתשמש בו בנוחות, עדיין מתחת לכל המעטים, ישנו ה-DOM
  • CSS – נועד לעיצוב מסמכים טכניים, ולכן עדיין קשה לעשות layout-ים מסויימים כי לא לכך הוא נועד. דבר נוסף הוא שבגלל שמשתמשים בו למשהו שאינו מטרתו המקורית, הוא יכול לשבור דברים.
  • JavaScript – שפה קשה, אבל יש בה דברים טובים 😉

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

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

  • למצוא דפדפן חדשני שיסכים לאינטגרציה עם הכלי שהוא יפתח
  • למצוא אתר אחד שיכריח את לקוחותיו להשתמש בכלי הנ”ל
  • הפחתת הסיכון תפתה משתמשים
  • לחץ תחרותי יגרום לאתרים אחרים להצטרף.

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

בשלב הזה הוא תיאר את הכלי הצורה מפורטת. שוב, אביא רק את עיקרי הדברים. בכלי שלו הוא מתכוון להשתמש בקריפטוגרפיה מתקדמת וחזקה (אי אפשר לסמוך על מה שקיים כיום, כי החברות חיבלו בזה); מעבר לזה, מתוך שלושת המאפיינים במשולש של זוקו – human meaningful, securely unique; Decentralized – הוא החליט לוותר על human meaningful ולדבוק בשניים האחרים. לכן הוא מתכוון להשתמש ב-ecc521 public keys בתור unique identifiers, וב-secure json over tcp במקום http, כי בעיניו, tcp היא מערכת מעולה מסיבות רבות, המרכזית שבהן היא היותה מערכת דו כיוונית ולא בקשה /מענה.

פירוש הדבר הוא שכל אדם יקבל כתובת URL כזאת:
web: publickey @ ipaddress / capability
לדעתו, הקידומת web: היתה צריכה להיות בשימוש של האינטרנט, אבל איש לא עשה זאת, אז הוא לוקח את הקידומת הזו לעצמו; ה-publickey יהיה בעל 105 תוים (הוא אמר שהוא מוותר על human meaningful…).

הוא המשיך לתאר את המערכת, אבל לא את הכל הצלחתי לסכם. עיקרי הדברים הם cooperation under mutual suspicion; הוא ישתמש ב-javascript message server או בקיצור QT. תהיה הפרדה לשכבות. אינו יכול להשתמש ב-node כי היא איננה מאובטחת מספיק, וגם לא בטוח שכדאי שיהיה שימוש ב-npm.
הרשת תמשיך לעבוד כמו שצריך – תאפשר לכל אחד ללכת לכל מקום בכל זמן ולעשות כל דבר ולפגוש אנשים. המגבלה היחידה היא שזה לא נועד למחוייבות, ולשם כך נשתמש במערכת החדשה.
קרוקפורד חושב שראוי שבכל דפדפן אפשר יהיה לכבות JS. מבחינתו, בפעם הראשונה שאנחנו גולשים לאתר אנחנו לא יכולים לבטוח בו, ואין שום דבר שנרצה לעשות בו שיחייב JS, ולכן צריך שבברירת מחדל JS, יהיה כבוי בגלישה הראשונה לאתר.
הכלי שלו אינו מבוסס על טכנולוגית חדשות, הכל כבר קיים. מה שנותן לו תקווה שזה יעבוד זה שיש תכנית מעבר, ושלא מנסים לתקן את הרשת.
בינתיים – הוא אינו מבקש מאיתנו לשנות שומדבר באופן בו אנחנו עושים דברים. הוא לא רוצה לכבול אותנו למערכת החדשה שלו לפני שהיא נבנתה. כל מטרתו היא להציע לנו תקווה.

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

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

 

גיל טיאר | Old Gods & New: A Vision of Backend & Frontend

על פתרונות בק-אנד לבעיות פרונט-אנד

את ההרצאה של גיל הייתי מתמצתת כקיצור תולדות ה-JavaScript בשנים האחרונות. הוא תיאר את  המתח בין מתכנתי פרונט-אנד למתכנתי בק-אנד בצורה סיפורית והומוריסטית – שבט מתכנתי הבק-אנד היה מתפלל לאלוהי הבק-אנד, שהבין רק Thread Spooling, Message queuing ו-Scala, ואילו שבט מתכנתי הפרונט-אנד נהג להתפלל לאלוהי הפרונט-אנד, שהבין רק HTML, CSS ו-JavaScript. בכל פעם ששבט מתכנתי פרונט-אנד נתקל בבעיה, הוא נאלץ ללכת לשבט מתכנתי הבק-אנד ולבקש מהם שיתפללו לאלוהי הבק-אנד שיפתור להם את הבעיה. הסיפור היה פינג-פונגי ומהיר, ולכן לא הצלחתי לזכור את כולו. זה מה שאני כן זוכרת:

  • קושי בסיומת HTML -> נפתר ע”י URL Rewriting.
  • תלות במתכנתי בק-אנד בשביל ה-rewriting;
  • רצו syntax חדש וחמוד – > קיבלו ES6;
  • זה ש-ES6 לא רץ בכל הדפדפנים -> משהו שמקמפל את זה ל-ES5;
  • כעת צריך קומפילציה, וכפתור ה-F5 מאבד מזוהרו -> ? ;
  • בעיית ריבוי קבצים -> כיווץ לקובץ אחד (bundle).
  • הפתרון האחרון היה שרת שיודע להתנהג כמו שרת (thread spooling, message queue, scala), אבל גם יודע JS. בקיצור – NODE.

 

Phil Nash | The web is getting pushy

על Push notifications בדפדפן.

המצגת של פיל. הקוד שנכתב בהרצאה.

ההרצאה של פיל נאש היתה על הודעות (notifications) בתוך הדפדפן, והיתה היתה מתובלת ב-Live coding.
לשיטתו, כשם שיש הודעות מתוך אפלקיציות, הוא רוצה שיהיה ככה גם באינטרנט.
דבר ראשון, הוא התחיל עם תכנית JS קטנה שבאמצעות ה-api של טוויטר מדפיסה על המסך הודעות מטוויטר. בעיות: א) זה איטי, ב) צריך לרפרש.
בשלב הבא הוא כתב קצת JS שמרפרש מעצמו. אבל עדיין זה בתוך הדף בדפדפן, ולא קופץ החוצה כמו בנייטיב.
הנסוי הבא שלו היה עם push notification: הוא השתמש ב-notification שמבקש רשות, ואז מראה הודעות בפינה הימנית העליונה של הדפדפן. כמו נייטיב. קיבל מחיאות כפיים. הבעיה היא שזה מפסיק כשסוגרים את הטאב, וש-push notification כמעט לא נתמכים בדפדפנים (בכרום רק מגרסה 42; בפיירפוקס מאחורי דגל; אופרה לא ידוע; ספארי לא תומכת; וכאן הוא שיבח את אקספלורר, על שהנושא נמצא אצלם Under consideration. מבחינתו זה עדיף מאופרה וספארי).
מכיון שכמעט אין לזה תמיכה, הוא עבר להשתמש ב-sever worker support, שנתמך קצת יותר (בכרום מגרסה 40; בפיירפוקס עדיין מאחורי דגל; אופרה גרסה 24; ספארי לא ידוע; באקספלורר, גם הנושא הזה נמצא Under consideration).. הוא השתמש ב-gcm כי זה אמין זה מה שמאחורי android.
היה מגניב לראות את ההודעות קופצות בפינה הימנית העליונה של הדפדפן (התוכנה שהוא כתב התממשקה עם טוויטר והראתה הודעות עם האשטאג מסויים, והוא ביקש את ההשתתפות הקהל בזה שישלחו ציוצים עם ההאשטאג הנ”ל).
לאחר שהוא הראה את היכולות הוא הזכיר שמאחר שיחד עם כוח גדול מגיעה גם אחריות גדולה, עלינו להשתמש בכח ההודעות באחריות: ראשית, לוודא שהמשתמשים יכולים לבטל את זה. שנית, להתייחס בכבוד ולשלוח רק דברים שהמשתמשים רוצים לדעת.

 

שי חן | Creepy frontend mistakes

שגיאות אבטחה בפרונט-אנד

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

  • כשאנחנו מקליקים על דברים – כפתור פליי בסרטון, למשל – יש סיכון שאנחנו מקליקים על דברים מוסתרים – שי הראה סרטון שהראה מתכנת אבטחה שהתבקש לנתח אתר שבו משתמשים יכולים לצפות בסרטונים. על אחד הסרטונים כתוב שהוא אסור לצפיה מתחת לגיל 16, מה שכמובן גורם לצפיות רבות. מאחר שצפיה נעשית ע”י הקלקה על כפתור הפליי, הסרטון הזה מקבל הקלקות רבות. מתכנת האבטחה, בעזרת פיירבאג, מוריד שכבות HTML, ופתאום רואים כמה הרבה אלמנטים מסתתרים מתחת לסרטון הזה!  שכבה הגבוהה ביותר ישנו כפתור הפליי, אבל בניתוח השכבות אפשר לראות שמתחת לסרטון – הרבה מתחת להרבה אלמנטים מסתירים ומוסתרים – יש כפתור לייק, שזז תמיד למיקום של סמן של העכבר, כך שהקלקה על הסרטון בעצם גורמת ללחיצה על כפתור לייק!
  • דברים ישנים: פעם מתכנתים נהגו לשים מידע רגיש ב-URL. מאחר ש-URL-ים נשמרים בהיסטוריה, הרי שכשנמצאים במחשב ציבורי מי שבא אח”כ יכול לעיין בהיסטוריה ולדלות נתונים מעניינים ושימושיים.
  • מחסן מידע נוסף הוא ה-autocomplete האוטומטי של הדפדפן. ה-autocomplete שומר את כל הטקסטים שהוכנסו לשדה בטופס, ומאד קל לשלוף את זה אח”כ. מתכנת של אתר המבקש מידע סודי ממשתמשים, צריך לעשות disable לפיצ’ר הזה שדלוק בבררת מחדל, אחרת אתר אחר עלול להשתמש בזה. שי הראה איך למשל אם הוקלד מספר כרטיס אשראי, ע”י פיתוי המשתמש להקליק על תמונה שבעצם פותחת autocomplete ואז ע”י שכנוע המשתמש לגרירה – גוררת את זה ל-iframe ולהעביר את המידע לאתר אחר… בכלל, כל הנושא של גרירה הוא פתח לפרצות, לכן עדיף להזהר מפזלים באינטרנט…
  • כידוע, כשמורידים קובץ מאתר, נפתח חלון עם 3 כפתורים: Run, Save, Cancel. לא רבים יודעים שבחלק מהדפדפנים אפשר להשתמש בקיצור מקלדת במקום ללחוץ על הכפתורים – R במקום Run; במקום Save מקלידים S; ו-C במקום Cancel. אם אתר רוצה לשהגולש ישמור במחשבו קובץ זדוני, הוא מסתירים את החלון ובמקומו מרא קפצ’ה, שבו אחת האותיות היא R או S, וכך גורמים לגולש לשמור או להריץ קובץ!
  • לפעמים באתרים של מכירות, בזמן הקניה נשלח גם שדה עם המחיר, או ההנחה. כמובן שמי שמבין בזה יכול לשנות את המחיר או את ההנחה… זו דוגמה של חוסר אבטחה שמתנקם באתר עצמו…
  • באופן כללי, ככל שמרחיבים את חוויית המשתמש בדפדפן, כמו קשינג ו-DB, יש יותר אפשרויות לתקיפה בצד לקוח. זה לא חייב להיות מחיקה, זה עלול להיות שליפה של מידע שלא אמור להשלף.

 

יפים דיאמנשטיין ואיתי צ’שנובסקי

דיברו על תהליכי עבודה עם ריבוי רכיבים ומתכנתים.

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

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

סרג’ קרול

ניהול צוות – בלי פחד, עם אהבה

סרג’ התחיל בתיאור סיטואציה: אתה ראש צוות, בסוף היום אתה עובר על ה-commit-ים, ורואה diff שבא לך לתקן. מה אתה עושה – מתקן או לא?

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

נתחיל מהפחד שיש בסיטואציה הזו: ממה אנחנו פוחדים?

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

כדי להתמודד עם פחד, סרג’ מחמש אותנו בכלי נשק של אהבה:

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

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

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

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

  • שתצטרך לבטל את התכניות שלך
  • שתצטרך להכריח מישהו אחר לטפל בזה, אולי כי לא נעים להכריח אחרים
  • הפרוייקט לא יעמוד בזמנים – וזה קריטי ללקוח

כלי נשק חדשים:

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

דיברנו על יחס לאחרים, אבל מה איתי? מי דואג לי?

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

אז הכלים ליצירת צוות הם:

  • תמיכה
  • בטחון
  • אמפטיה (כבוד)
  • גבולות

והכלים ליצירת מנהיגות הם (יש הרבה פחות ערכים במנהיגות, כי זה רק קשור אליך):

  • להרפות
  • לתת לצמוח

צוות הוא כמו משפחה – צוות טוב זה כמו משפחה טובה, לא משפחת רווחה. צוות הוא לא JS, ומנהיגות היא לא אנשים אדומים*.

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

*כשסרג’ ערך חיפוש על תמונות של מנהיגות, עלו לו המון תמונות עם אנשים אדומים.

 

ולדימיר גריננקו וילנה ג’טפיספייבה

כתיבת CSS מודולרי וקל לתחזוקה, גם במערכת גדולה ומרובת מתכנתים

המצגת.

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

  • קושי בתחזוקת קוד שמישהו אחר כתב (כשהמישהו האחר הזה עשוי להיות אתה, לפני חודש…)
  • CSS כתוב בכלליות: #foot div div*
  • קשה להשתמש שוב (reuse) בקוד קיים: קשה להבין מה לשכפל, קשה לשעת מה מיותר, ועדכון קוד הוא פשוט סיוט.
  • שימוש ב-framework-ים רבים
  • אין ניהול תלויות (dependencies)

חלק מהבעיות הללו נובעות ממגבלות של CSS – אין לו scoping (אי אפשר לתחום הגדרות כלליות כך שתחולנה רק על חלק מהקוד); קונפליקטים של specificity (שכמובן גוררים שימוש ב-important).

הפתרון: BEM
Block, Element, Modifier

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

  • בלוק – בד”כ משהו כמו טופס חיפוש, או כותרת, תפריט, וכד’.
  • אלמנט – שדה טקסט, טאב, וכד’.
  • השינוי – אם למשל הפריט מקבל עיצוב שונה מפני שהוא הפריט הנוכחי בתפריט, ה-modifier שלו יהיה current

מספר עקרונות של BEM:

  • לא משתמשים בסלקטורים של id, ולא של תגית (תגית היא כללית מדי, ומצריכה קונטקסט. BEM מבקש שכל סלקטור יהיה עצמאי ולא יצטרך לדעת בתוך איזה אלמנט הוא יושב כדי להחיל עליו עיצוב)
  • אין CSS מחוץ לבלוקים
  • כל בלוק הוא עצמאי – אין reset גלובלי
  • נמנעים מ-cascade בין בלוקים, כדי שכל בלוק יעמוד בפני עצמו מבחינת CSS.

העקרונות הללו מאפשרים את הדברים הבאים:

  • בלוקים עצמאיים הניתנים לשימוש חוזר (reuse)
  • בטחון שאיננו הורסים משהו
  • אפשר בקלות לדרוס כללים קודמים (override)
  • קוד שמתעד את עצמו

מכאן הם המשיכו והרחיבו את המודל – לשימוש ב-JS וב-XSL, ואת זה כבר לא סיכמתי. אפשר להמשיך להסתכל במצגת (החל משקף 32), ואפשר לקרוא עליו במקומות המכובדים הבאים: סמשינג מגזין על BEM; מאמר של css-tricks על BEM; ב-Sitepoint על BEM; ו-Csswizardry על BEM. יש עוד, רק תשאלו את גוגל 🙂 .בחלק מהמאמרים יש גם סיקור של החסרונות של BEM, שבעיניי זה חשוב מאד.

 

מופע הקוסמות של מרטין קלפ – The Aleph

אמנות המינימליזציה ב-JavaScript.
אבל זה לא מתחיל אפילו לתאר את הגאונות שיש בהרצאה הזאת.

המצגת.

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

להרצאה שלו, קרא מרטין “הָאָלֶף”. הוא סיפר שלכל כנס שהוא מוזמן אליו, הוא אוהב ליצור משהו מיוחד (איזה יפה זה, נכון?). לכנס שלנו הוא יצר קוד JS שמבוסס על האות א’. התוצר הוא המשחק Life, ואם תעשו view source לדף, תרא שכל הקוד כתוב באותיות עבריות. איזה מחיאות כפיים הוא קיבל על זה!

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

הדבר הבסיסי הראשון הוא – לכתוב תוכנת JS בצורה המינימלית ביותר האפשרית. במצגת, משקף 22 עד שקף 46, הוא מראה את האבולוציה של תוכנית קטנה מבחינת תגיות HTML. מתברר שאפשר להשמיט הרבה תגיות (כמו head ו-html עצמו), והדפדפן עדיין יבין וירנדר את הקוד.
משקף 47 עד שקף 60, הוא מראה כמה אפשר להשמיט ב-JS עצמו. אז ברור שאפשר להשמיט את var (כמובן שלאורך כל המצגת הוא חזר והזהיר לא להשתמש בטכניקות הללו בפרודקשן 🙂 ), אבל אפשר גם להשים שמות של פונקציות למשתנה בעל אות אחת, ואז להשתמש באות הזאת כקריאה לפונקציה.

בדרך לדבר הבסיסי השני הוא סיפר שהוא מנסה לשאוב השראה מכל דבר. הוא סיבר על השראה שקיבל מ-.Jorge Luis Borges, אמן הסיפור הקצרצר. ואז הוא סיפר שהוא גילה והתפעל מהאות א’, שיש לה גם משמעות קבלית (לפי דעתי הוא ידע דברים שרבים בקהל לא ידעו…), והחליט על בסיסה ליצור את המשחק Life שכלליו מוסברים משקף 87 עד 103.

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

הדבר השני הבסיסי הוא – לכתוב תוכנית ב-JS ללא תוים לטיניים. מהו המספר המינמלי של תוים שצריך כדי לכתוב תכנית JS? מתברר ש-6: ()+[]! איך זה יכול להיות? הנה הדברים המוזרים והנפלאים ש-JS מאפשר:

![] מחזיר false, ו-!![] מחזיר true. אם מוסיפים לכל אחד מהביטויים הללו מחרוזת ריקה – ![] + "" ו-!![] + "" – מקבלים את המחרוזת "true" ו-"false" בהתאמה. מכאן זה משחק של שבץ נא: "true"[0] מחזיר "t", וכד’ (שקף 164). עד שקף 167 הוא מראה איך כותבים כך את המילה alert (מחיאות כפיים סוערות!).
בשקפים 152 עד 159 הוא מסביר איך הביטוי הבא מריץ את ה-alert (אני כבר לא זוכרת למה לא מספיק לכתוב alert(1) בלבד):

[]["map"]["constructor"]("alert(1)")()

מתברר ש-

[]["map"] = function

וכמו”כ,

function["constructor"] = Function

ולבסוף,

Function("alert(1)") = eval("alert(1)")

כעת, אם ניקח את השיטה השבצנאית אותה הוא הראה לעיל, לחילוץ אותיות מתוך מלים, אפשר ליצור את האותיות של map ו-constructor מתוך מלים כגון object, undefined, true ו-false (שקף 169), וכך לכתוב את התכנית הנ”ל תוך שימוש בששת התוים לעיל בלבד.

מ-ח-י-א-ו-ת  כ-פ-י-י-ם  ס-ו-ע-ר-ו-ת !!!

5 תגובות על “כנס You Gotta Love Frontend – היום הראשון

כתבו תגובה

כתובת הדוא"ל שלכם לא תוצג.