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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קוד ה Assembly של התוכנית:

a.out[0x100000ed0] <+0>:   pushq  %rbp
a.out[0x100000ed1] <+1>:   movq   %rsp, %rbp
a.out[0x100000ed4] <+4>:   subq   $0x30, %rsp
a.out[0x100000ed8] <+8>:   leaq   0xad(%rip), %rax          ; "What's the password?\n"
a.out[0x100000edf] <+15>:  movl   $0x0, -0x4(%rbp)
a.out[0x100000ee6] <+22>:  movl   %edi, -0x8(%rbp)
a.out[0x100000ee9] <+25>:  movq   %rsi, -0x10(%rbp)
a.out[0x100000eed] <+29>:  movl   $0x0, -0x14(%rbp)
a.out[0x100000ef4] <+36>:  movq   %rax, %rdi
a.out[0x100000ef7] <+39>:  movb   $0x0, %al
a.out[0x100000ef9] <+41>:  callq  0x100000f5c               ; symbol stub for: printf
a.out[0x100000efe] <+46>:  leaq   0x9d(%rip), %rdi          ; "%d"
a.out[0x100000f05] <+53>:  leaq   -0x14(%rbp), %rsi
a.out[0x100000f09] <+57>:  movl   %eax, -0x1c(%rbp)
a.out[0x100000f0c] <+60>:  movb   $0x0, %al
a.out[0x100000f0e] <+62>:  callq  0x100000f62               ; symbol stub for: scanf
a.out[0x100000f13] <+67>:  movl   %eax, -0x18(%rbp)
a.out[0x100000f16] <+70>:  cmpl   $0x1, -0x18(%rbp)
a.out[0x100000f1a] <+74>:  jne    0x100000f52               ; <+130>
a.out[0x100000f20] <+80>:  movl   $0x7, %eax
a.out[0x100000f25] <+85>:  movl   -0x14(%rbp), %ecx
a.out[0x100000f28] <+88>:  movl   %eax, -0x20(%rbp)
a.out[0x100000f2b] <+91>:  movl   %ecx, %eax
a.out[0x100000f2d] <+93>:  cltd   
a.out[0x100000f2e] <+94>:  movl   -0x20(%rbp), %ecx
a.out[0x100000f31] <+97>:  idivl  %ecx
a.out[0x100000f33] <+99>:  cmpl   $0x0, %edx
a.out[0x100000f36] <+102>: jne    0x100000f4d               ; <+125>
a.out[0x100000f3c] <+108>: leaq   0x62(%rip), %rdi          ; "Correct!\n"
a.out[0x100000f43] <+115>: movb   $0x0, %al
a.out[0x100000f45] <+117>: callq  0x100000f5c               ; symbol stub for: printf
a.out[0x100000f4a] <+122>: movl   %eax, -0x24(%rbp)
a.out[0x100000f4d] <+125>: jmp    0x100000f52               ; <+130>
a.out[0x100000f52] <+130>: movl   -0x4(%rbp), %eax
a.out[0x100000f55] <+133>: addq   $0x30, %rsp
a.out[0x100000f59] <+137>: popq   %rbp
a.out[0x100000f5a] <+138>: retq   

וקובץ ה Executable בגירסת מק זמין להורדה מכאן: https://www.tocode.co.il/system/ex1

וכמובן אם בא לכם לשחק עם קראקמיס יותר מקצועיים יש אוסף נחמד בקישור כאן: https://crackmes.one/lasts

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

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

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

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

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

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

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

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

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

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

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

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

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