הבלוג של ינון פרק

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

1. נוספה אפשרות למנוי שנתי, בו אתם משלמים על 10 חודשים מראש ומקבלים את החודשיים האחרונים מתנה.

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

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

4. נוסף "מצב חשוך" למי שאוהבים לקרוא מהטלפון בלילה.

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

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

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

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

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

The HTML autocomplete attribute lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field.

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

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

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

<form method="post" action="/form" autocomplete="off">
  …
</form>

או ברמת ה input:

<input type="text" id="cc" name="cc" autocomplete="off" />

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

נ.ב. דוגמה? יאללה דוגמה. הנה קודפן: https://codepen.io/ynonp/pen/RwJPYYX. בקישור הזה אפשר לראות אותו על מסך מלא:

https://cdpn.io/pen/debug/RwJPYYX

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

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

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

1. תוכלו לעשות ישיבה פעם בכמה זמן לעבור על קומיטים ולראות איזה מהם אתם אוהבים ואיזה לא.

2. תוכלו לזהות קומיטים שאתם לא אוהבים ולתקן אותם באמצעות ריבייס.

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

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

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

מישהו ברדיט שאל השבוע - "אם אני רוצה לכתוב פרויקט כדי להוסיף אותו לקורות חיים, האם אפשר להשתמש בכלים המובנים בפריימוורק גם לחלקים שאנשים רואים? לדוגמה אם אני משתמש ב Django כדי לבנות אפליקציית ווב, האם אפשר להשתמש ברכיב ה Login המובנה ב Django?"

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

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

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

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

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

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

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

בעבודה על פרויקט Node.JS לבחירה בטייפסקריפט יש גם יתרונות וגם חסרונות עליהם נדבר בשיעור זה.

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

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

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

3. אפשר לקבל תוצאות טובות ובזול עם VPS או שרתים פיזיים - לינוד עדיין משכירים שרת VPS זול ב 5 דולר בחודש, ומכונות טובות ב 40$ בחודש. כן, נצטרך לעבוד קשה בשביל לקבל High Availability במובן שאם Region שלם נופל המערכת אוטומטית תתחיל לעבוד מ Region אחר או מ VPS אחר, אבל גם זה אפשרי ובכל מקרה לעסקים קטנים לא בטוח כמה זה הכרחי.

4. בעזרת Kubernetes ו Docker (לא מכירים אותם עדיין? יש קורס) אפשר לקבל חוויה מאוד דומה ל Deployment האוטומטי של חברות הענן, אבל בשליטה שלכם ועם תמיכה טובה במצב פיתוח, ואפשרות לעבור מהר בין ספקי תשתית.

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

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

לא מזמן נתקלתי בטריק החמוד הזה בריאקט שרציתי לשתף, לא בשביל שתשתמשו בו בפרודקשן אלא יותר כ Proof Of Concept, כדי להבין עוד דבר או שניים על פורטלים ו ref.

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

אתם כבר יודעים להשתמש ב useEffect כדי להריץ קוד כשמשהו משתנה, ולהשתמש ב useRef כדי לתפוס אלמנט ב DOM אחרי render, אבל בשילוב בין השניים יש טעות שמאוד קל לעשות. בואו נראה קצת קוד.

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