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

חבר שלח לי לינק לספריית Server Side Rendering חדשה בשם iSSR. בתוך הדוגמה בתיעוד אנחנו מוצאים את השורה הבאה:

const { html, state } = await serverRender(() => <App />);

אבל בשום מקום באותו דף תיעוד לא מופיעה המילה cache. זה אומר שאם אני לא יודע כלום על Server Side Rendering ורק קורא את התיעוד של הספריה, יש סיכוי טוב שאצליח לבנות קוד SSR בעזרתה אבל כשהקוד הזה יגיע למשתמשים אמיתיים השרת ייפול מהעומס.

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

1. מה עולם התוכן הרלוונטי של הספריה הזו?

2. איזה ספריות אחרות אני מכיר שפותרות את אותה בעיה?

3. מה הבעיות הכי נפוצות בשימוש בספריות מהסוג הזה?

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

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

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

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

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

עכשיו בואו נדבר על כסף.

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

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

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

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

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

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

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

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

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

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

אחד הצעדים בדרך מ Junior ל Senior הוא היחס לבעיות חדשות ולא מוכרות.

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

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

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

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

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

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

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

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

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

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

1. איך מדבגים את זה?

2. מה מינימום בדיקות שצריך לכתוב בעבודה על פיצ'ר?

3. למה אנחנו עושים Mock בבדיקה? ולמה לא?

4. מה שומרים ב git?

5. מה הפורמט של הודעת קומיט?

6. איך מעלים גירסה?

7. איך פותחים פרויקט חדש? מה צריך להתקין כשמקבלים מחשב חדש?

8. מה עושים כשכמה אנשים צריכים לעבוד על פיצ'רים שונים בפרויקט?

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

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

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

$ sudo apt-get install pm-utils

חבילת pm-utils כוללת שתי פקודות מעניינות. הראשונה מכניסה אותנו למצב חיסכון בחשמל:

sudo pm-powersave true

והשניה חוזרת למצב עבודה רגיל:

sudo pm-powersave false

פקודות אלה מחפשות סקריפטים בתוך תיקיית /etc/pm/power.d ויריצו את כל הסקריפטים שם לפי סדר, כשכל סקריפט מופעל עם הפרמטר true או false (הפרמטר true מציין כניסה למצב חיסכון בחשמל, false מציין יציאה ממצב זה).

עד לפה הכל טוב ויפה אבל רובנו לא הולכים לזכור כל פעם שאנחנו מנתקים את המחשב מהחשמל גם להריץ את הסקריפט של pm-powersave ולכן צריך עוד שינוי קטן כדי שמנגנון זה ירוץ אוטומטית בעת ניתוק או חיבור המחשב לחשמל. אחרי חיפוש קצר ברשת מצאתי שדרך קלה לעשות את זה היא להוסיף udev rule. בתור מנהל מערכת ניצור את הקובץ /etc/udev/rules.d/99-powersave.rules ובתוכו נכתוב:

SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/usr/sbin/pm-powersave true"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/usr/sbin/pm-powersave false"

לאחר מכן הפעילו את הפקודה הבאה כדי לרענן את כללי ה udev:

udevadm control --reload-rules && udevadm trigger

וצרו את הסקריפטים שאתם צריכים בתיקיית /etc/pm/power.d. כל סקריפט שתיצרו שם יופעל אוטומטית כשהמערכת נכנסת למצב חיסכון בחשמל או יוצאת ממנו. בדף התיעוד על ניהול צריכת חשמל תוכלו למצוא דוגמאות לסקריפטים כאלה וכלים שיעזרו לכם לצמצם את צריכת החשמל של המחשב כשהוא לא מחובר לקיר.