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

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

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

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

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

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

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

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

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

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

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

הבעיה הראשונה היא הסביבה התומכת. מסתבר שכשהם מאחרים אנחנו מחכים להם.

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

אז מה הסיבה לאיחורים?

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

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

האלטרנטיבה היא פשוטה להבנה אך קשה לביצוע- פשוט אומרים לא.

תגידו את זה בלי להתרגש ובלי להילחץ. ״אני מצטערת, נגמר הזמן״.

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

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

וגם הזמן אם תבחרי בכך.

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

והכי גרוע- אתם כל הזמן לחוצים.

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

צריך ללכת. זמננו תם.

...

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

אגב1 המקור כאן:

https://seths.blog/2019/01/good-intentions-how-to-be-on-time/

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

עם השידרוג ל Webpack 4 גם כל ההגדרות של הכלי הפכו הרבה יותר פשוטות והיום בהרבה פרויקטים כבר לא צריך להתחיל עם משהו גדול כמו create-react-app ואפשר יחסית בקלות לבנות לעצמכם קובץ הגדרות Webpack שיגדל יחד עם הפרויקט שלכם.

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

מי מהיר יותר- אנגולר או React? ומה יותר בטוח- קוד פתוח או קוד סגור? ומה, לא שמעתם ש MySQL כבר מת, וכולם עברו ל Mongo?

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

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

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

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

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

הם לא.

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

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

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

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

המערכת לא באוויר אבל הקוד זמין בגיטהאב בקישור הזה:

https://github.com/ynonp/secure-code-livedemo-loby

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

זה דף הוובינר לפרטים והרשמה:

https://www.tocode.co.il/workshops/61

נתראה בחמישי, ינון

אם תפעילו את Express Generator בלי לציין View Engine תקבלו פרויקט שמשתמש ב View Engine בשם Pugs, אבל פעם קראו לו Jade והרבה אנשים ממשיכים עם השם הישן. מדובר על מנוע תבניות שבגדול הוא ממש נוח במיוחד בהשוואה ל EJS.

קחו דף HTML סטטי לדוגמא:

<div>
  <h1>Ocean's Eleven</h1>
  <ul>
    <li>Comedy</li>
    <li>Thriller</li>
  </ul>
</div>

אנחנו יכולים לכתוב אותו ב Jade ולקבל דף הרבה יותר נקי:

div
  h1 Ocean's Eleven
  ul
    li Comedy
    li Thriller

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

<div>
  <h1>Ocean's Eleven</h1>
  <ul>
    <% items.forEach(function(item) { %>
        <li><%= item %></li>
    <% }) %>
  </ul>
</div>

ואותו דף עם רשימה דינמית ב Jade:

div
  h1 Ocean's Eleven
  ul
    each item in items
    li= item

או קוד עבור קישור ב EJS:

<a href="<%= link.href %>"><%= link.text %></a>

לעומת Jade:

a(href=link.href)= link.text

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

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

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

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

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

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

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

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

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

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

1. מערכת לניהול Affiliates- אפשר להירשם אליה ולהגדיר Affiliate חדש והמערכת כבר תנפיק אוטומטית את הלינק לתת לאותו Affiliate ותגיד לכם כמה ערוץ המכירה הזה היה אפקטיבי.

2. מערכת CRM (כן, עדיין אנשים משתמשים בכאלה). תראו לדוגמא את Powerlink CRM הישראלים.

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

4. מערכת הזמנות לאירועים, כולל אישור הגעה בווטסאפ.

5. מערכת ניהול יומנים לחדרי בריחה (או לספרים, או למטפלים הוליסטיים).

6. מערכת לפיתוח בוטים לטלגרם. כמו כמו זה: https://instamake.io/bots.html

7. מערכת לניהול ושליחת וידאו- אתה מעלה וידאו ויכול להטמיע אותו באתרים. קצת כמו יוטיוב אבל עם אפשרות להגבלת גישה, לאנאליטיקס וכו'. כמו זה: https://wistia.com/

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

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

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