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

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

כמו את היום הראשון, גם את היום השני התחילו עם גורו. אחלה שיטה.

בסוף ההרצאה שלה גם נתנו לה פרחים. [ואני אומרת: אפליה מגדרית! למה לקרוקפורד לא נתנו פרחים???]

ליה ורו | The missing slice

איך ליצור גרף עוגה ב-CSS. מבוסס על סוד מס’ 14 בספר שלה, CSS Secrets.

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

פתרון ראשון:

אם גרף העוגה הוא רבע, אפשר ליצור אותו בעזרת גבולות (border-ים) עבים,  bordr-radius,  ו-rotate. אפשר גם עם before ו-skew.

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

יש 3 מרכיבים לפתרון CSS טוב:

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

נסתכל כעת על הפתרון של ה-skew מבחינת הפרמטרים הללו:

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

פתרון שני:

לצבוע את צבע הרקע עם גרדיאנט. אפשר להשתמש ב- rotate בערך של turn.  בתור צבע רקע צריך לעשות inherit  כדי לא להצטרך לשנות את הצבע בשני מקומות.

פתרון שלישי:

אינטרפולציה – חישוב של נקודות ביניים בין תחילה לסוף של אנימציה. אפשר להשתמש בזה כדי לעצור אנימציה, וליצור delay שלילי, כדי להראות חלקי צבעים.
במקרה של 100, צריך לבטל את infinite  ולעשות forwards.
כדי לעשות זאת על הפסאודו אלמנט, קובעים animation-delay על ההורה, וזה לא עושה כלום, ואז לפסאודו אלמנט קובעים inherit  . ככה אפשר לשנות את זה ב-JSב-SVG  אפשר להשתמש ב-CIRCLE  ואז לקבוע stroke  dasharray  בקואורדינטות של 64 כדי שהכל יהיה 100
אפשר ליצור כמה חלקים

פתרון אחרון:

Conic Gradients – זה מאפיין חדש של CSS שעונה בדיוק על הצורך של גרף עוגה. היא הראתה דוגמה מקסימה עם קוד קצר וברור (עונה על כל הקריטריונים דלעיל) ועושה את העבודה נהדר. הבעיה היחידה איתו הוא שהוא אינו נתמך עדיין בשום דפדפן, לכן ליה ורו מבקשת מאד שננדנד לדפדפנים – הם תומכים במאפיינים לפי כמות בקשות הקהל. אחד האנשים בקהל שאל אותה: אם המאפיין הזה לא נתמך בשום דפדפן, איך הראית לנו את הדוגמה הזאת? ענתה הגורו: אה, כתבתי לזה פוליפיל… (כאילו, בינינו, מה זה לכתוב פוליפיל. אמרנו הגורו?)

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

גרף עוגה מונפש.

 

בנימין גרינבאום | io.js and the future of server side JavaScript

הקלות שבה ניתן להצטרף לפרוייקטי קוד פתוח.

בנימין התחיל בהסבר על io.js ומה הוא לעומת node.js. אבל בעצם המטרה שלו היתה להראות כמה פשוט לסייע בפרוייקט קוד פתוח.

הוא התחיל בדברים כלליים:

• עדיף לעשות pull requests מלבקש לתקן – אם מצאתם באג באיזשהו קוד פתוח, קחו אליכם עותק ותקנו אותו. זה הרבה יותר עוזר מאשר רק לדווח על הבאג ולבקש שיתוקן.
• לפתוח issues מאד עוזר – מצאתם באג? אל תתביישו. תפתחו issue. המפתחים של הקוד מאד אוהבים את זה, כי הם לא יכולים לעלות בעצמם על כל הבאגים, ולכן דיווח מהשטח עוזר להם לשפר את הקוד.
• לא לפחד לעשות מעצמכם צחוק – האם יתכן שבהשתתפות בדיונים על הקוד תשפילו את עצמכם? בהחלט. אבל אל תתנו לזה לעצור אתכם. הערך המוסף שתקבלו מההשתתפות יעלה על ההפחתה באגו שלכם.
• לענות על שאלות ב-SO – עזרה לא חייבת להיות בפיתוח או בתיקון באגים. גם לעזור לאנשים אחרים שמשתמשים בקוד הזה – זה מאד מועיל ומסייע.
• לכתוב תיעוד – תיעוד של פרוייקט הוא מאד חשוב, וקשה. אתם יכולים לכתוב תיעוד איפה שתרצו – אפילו בבלוג שלכם – ואנשים יגיעו לזה ע”י חיפוש. זה גם משהו שמאד עוזר להשתמש בקוד.

בשלב הזה הוא סיפר על ההשתלבות שלו ב-node:

promise הוא אובייקט ב- ECMAScript 6 בביצוע פעילות אסינכרונית. הוא מחזיר כשלון או ערך. הערך הוא immutable, אפשר לסמוך עליו.
בנימין מצא קטע קוד שבו משתמשים ב-promise, אבל איו אחריו catch, ואם כך – לעולם לא יבוצע קוד ואף אחד לא ידע על כשלון.
סיפר איך השתתפות ב-SO ונסיעה לפינלנד עזרו לו להכנס לעזרה ב-io.js.

סיים בקריאה: פיתחו  issue!

 

מת’יו מיירן | Nothing else matters: Easy backend for frontend developers

מציג מוצר חדש מבית Google, בשם Firebase.

אנחנו רוצים לפתח frontend, אבל צריכים למצוא מישהו שיעשה backend, וקשה למצוא.

בנוסף, backend הוא מסובך:

• צריך לעבוד על כמה פלטפורמות
• קשה לסכרן בין מקומות – wireless, 3G, מאבדים את הקשר. צריך לעשות merge כמו שצריך
• אם המוצר מצליח – צריך לעשות scale

מה הופך מוצר לממכר? הודעות (notifications)! כי מלבד המראה היפה, זה גם עונה על הרצון של אנשים לדעת דברים בזמן אמתי.

אז איך אפשר להביא פיצ’רים של בוזמניות לאפליקציה בלי לעבוד קשה מדי? Firebase.

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

הקונספטים של Firebase:

• DB – nosql
• דוחף הודעות במילישניות;
• אבטחה שמאפשרת גישה ישירה
• בוזמני
• ניהול משתמשים – צריך לנהל סשן
• מאפשר להשתמש בשם משתמש וסיסמה, או להשתמש בצד שלישי
• אפשר לעשות hosting לשרת
• מתממשק להרבה כלים – react, node, java
• עובד אופליין כי מאמינים שהמכשיר שלך יותר חזק משרת
• מה צריך (שקף)
• אוסף נתונים של הקלקות
• בנגוד ל-api זה מייתר את הצורך למשוך את ההודעות מתוך הקוד

 

אלכסנדר מפייסבוק

במילה אחת: React

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

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

ולכן הכי טוב להשתמש בכלים המעולים של אינטרנט כדי ליצור נייטיב מעולה – והפתרון הוא React.

המאפיינים של React:

• הפונקציות של react מחזירות virtual dom ולא HTML שזה תיאור של ה-DOM
• כש-JS קורא לפונקציה של נייטיב צריך לחכות, שזו כמובן בעיה. לכן צריך משהו א-סינכרוני. ועדיין, משהו א-סינכרוני זה לא מספיק כי יש overhead שמצטבר והפתרון הוא לעשות batch.
• איך משתמשים באותם משתנים גם ב-JS וגם בתהליכים של מעהה”פ? לכאורה צריך שיתוף משתנים, אבל גם זה לא טוב כי זה מקשה על קישור ואיסוף זבל. הפתרון של React הוא החלפה (exchange) וסירליזציה. יש גשר בין האובייקטים
• גם ניהול מגע אינו טריוויאלי – השאלה העיקרית היא איזה אלמנט צריך להגיב למגע: כשנוגעים, קצה האצבע נוגע באלמנט, ולפי הקואורדינטות יודעים אם זה בכפתור או לא. אבל אם נוגעים, ואז מחליקים את האצבע מחוץ לכפתור, ואז מרימים את האצבע, אז הנגיעה מתבטלת. דברם קטנים אך חשובים. וכל זה משתנה כשנמצאים במוד של גלילה. React הופך את הכל לפשוט יותר
• UI = f(data)

 

אלכס וולקוב | Coding Your Company Culture

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

אחת הדרכים להנות בעבודה היא לעבוד על פרוייקטים צדדיים.

מה היתרונות של פרוייקט צדדי?

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

• אתה הבוס
• אין דד ליינים
• ללמוד דבר חדש
• להעשיר את התרבות הארגונית

פרוייקטים לדוגמה:

• BOT-ים, במיוחד של צ’ט:
  • במיוחד hubot. אפשר להטמיע בצ’ט של הצוות. יש תיעוד פשוט. אפשר להקים על  heroku.
  • הוא הטמיע שימוש ב-can i use מתוך הצ’ט
  • משתמש אוטומטי שמאחל החלמה מהירה על הודעה על מחלה. בגלל שזה קוד פתוח אפשר להוסיף איחולים או לשפר את הביטוי הרגולרי
  • chat ops – לבצע deployment מתוך הצ’ט: @skip deploy staging
• אינטגרציה מבחוץ מתמשכת
• לא להמציא את הגלגל מחדש, אלא לעסוק בהתאמות
• dashing.io.אפשר להעתיק מהם
• dashboard.sidlee.com – מטריצה על דברים שגרתיים בעבודה – כמה צעדים אנשים צעדו, כמה פעמים פתחו את המקרר, כמה פעמים אנשים לחצו על ctrl+z, ועוד – כיד הדמיון הטובה.
• להרחיב את האינטרנט – לכתוב תוסף לכרום. אלכס למשל כתב תוסף לכרום שעוזר ב-diff של github. אפשר גם לכתוב תוסף שמתאים רק לצות שלכם – יש אפשרות להגביל את ההורדה של תוסף רק לאנשים מחברה מסויימת
• עוד דבר שאלכס בנה – אתר לעובדים חדשים, עם כל המידע שעובד חדש יכול להצטרך, בצורה נעימה וידידותית

 

אור הילץ’ | Binary Data Adventures in Browser JavaScript

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

 

יגאל סטקלוב | Landing your dream job as a FED

המצגת

איך להפוך לכוכב

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

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

מדוע איינו גורואים וכוכבים?

זה לא קורה כי אנחנו לא רוצים לזוז מאזור הנוחות שלנו. להראות את העבודה. למה?

למה שנרצה להיות כוכבים?

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

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

• כמו יוגב ב-codepen שזכה להופיע במצגת של ליה ורו.
  github – כמו סרגיי ברשימת הדברים שצריך לקרוא

אתם לא בולטים – לא מדגישים את הדברים הנכונים בקורות החיים:

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

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

 

ערן מ-depulse | דיבר על BOOM Performance – the required ingredient for any successful web product

איך ליצור ביצועי BOOM

יש מהר,
יש מהר מאד,
ויש בום!

סדרי גודל של עליית אתר:

10 שניות מרגיש כאילו זה לא עובד. אחרי שניה, עוברים למחשבות אחרות
0-100 מילישניות זה הזמן האופטימלי.

למה בום חשוב? מהירות משפיעה על המוצר. ככל שהמהירות עולה, יותר אנשים ישתמשו במוצר. ערן, למשל, משתמש בגוגל כ-spell checker וכמחשבון כי הוא כ”כ מהיר. כשזה מהיר יותר, ה-UI יהיה פשוט יותר.
בום יוצר התמכרות. השקיעו במהירות. סתם פיצ’ר חדש משפר ל-10% מהמשתמשים. מהירות – משפרת ל-100% מהמשתמשים

איך משפרים?

• לעשות minify JS ו-CSS
• להשתמש ב-gzip
• לעשות אופטימיזציה לתמונות
• כשמתמשים בספריות בלי לדעת מה קורה בפנים, עלולים לירות ברגל. למשל אם מחשבים אלמנט כמה פעמים, במקום פעם אחת או להשתמש בשרשור.
• מה מכביד על ה-DOM?
  • פינות עגוות, צל שקיפות
  • לא להשתמש ביותר מדי אלמנטים
  • להשתמש ב-gpu rendering כדי להגביר ביצועים. אבפר להכריח את הדפדפן להשתמש בזה אם משתמשים במאפיין transform: .translate
  • פעולות אופטימיות. להתחיל לבצע פעולות ששייכות לשלבים הבאים, עוד לפני שהמשתמש מגיע לשלבים הללו. למשל:
    • באינסטגרם יש שלושה שלבים שצריך לבצע כדי להלעתו תמונה. בפועל, המערכת מעלה את התמונה עוד לפני שהמשתמש ביצע את כל השלבים ומילא את כל השדות. התוצאה היא שכשהוא יגמור למלא, התמונה תופיע מיד. נכון שזה אומר שחלק מהתמונות מועלות בלי שהשמתמש סיים את התהליך, ולכן יש תמונות מיותרות על השרת, אבל זה מחיר ששווה לאינסטגרם לשלם כדי להעצים את חוויית המשתמש.
    • בפייסבוק שולחים את האג’קס, ואת התוצאה כותבים לא ב-success, אלא בכל מקרה. הם אופטימיים שהפעולה תהיה מוצלחת
    • בקיצור, אם יודעים מה התוצאה המצופה, הניחו שזה עבד ורנדרו את זה סופר מהר בדפדפן. אם זה לא עובד – אל תעשו שומדבר.
  • ניבוי פעולות: המשתמשים שלכם צפויים – תעקבו אחרי הפעולות, ותעלו את זה ללקוח.
    • prefetch, prerender, preconnect.
    • ספריות שמסייעות: typhead.js, lunr.js
    • תשתמשו ב-Local storage כי Local storage is your friend
    • הכי טוב להביא את המידע כבר עם עליית הדף – The fastest request is no request
  • ביצועים  נתפסים (perceived performance). אם אחרי כל השיפורים לעיל, עדיין יש עיכוב בעליה/ביצוע, אפשר “לעבוד” על הגולש ולתת לו תחושה של עדכון מהיר למרות העיכוב. אמצעים לדוגמה:
    • אנימציה – אבל לא יותר מ-100 מילישניות
    • ה-placeholdr של פייסבוק – gradual ui loading
    • אפקטים על כפתורים – ladda.js

לסיכום:

• ביצועים טובים = משתמשים שמחים
  לא לדלג על אופטימיזציה בסיסית
  אם לא חייבים לחכות לשרת – לא לחכות
  להביא את המידע מיד לפני שהמשתמש צריך
  אם לא מצליחים לעשות – לזייף