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

למתכנתים וותיקים שעבדו עם כלי ניהול גירסאות בעבר אמור לקחת בדיוק עשר דקות למצוא את שתי הפקודות החשובות בגיט: checkout ו commit. עוד כמה שעות של עבודה ואתם כבר שולטים גם ב add ו clone ואולי אפילו ב diff ויכולים להמשיך לעבוד כאילו אתם עדיין עם SVN. עד שמתחילות הצרות.

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

סיבה שניה היא פוטנציאל הרווח. כי אם אתם עובדים בגיט כמעט בטוח שאתם יכולים להפיק יותר מהכלי אם תדעו לעבוד נכון עם בראנצ'ים, לשלב ביניהם ולהזיז קוד בין הבראנצ'ים השונים. ואם תכירו טוב את ההבדל בין ה Staging Area, ל Local Repository ול Remote Repository תוכלו להשתמש בצורה חכמה יותר בכל אחד.

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

הרשמה בחינם בקישור:

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

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

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

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

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

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

https://hackernoon.com/the-trap-of-sales-driven-development-89e16c5e292f

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

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

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

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

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

״הלקוח שלי לא נותן לי לכתוב בדיקות בפרויקט״

״הלקוחה שלי מתעקשת שהאתר יהיה כתוב בוורדפרס״

״נמאס לרדוף אחרי לקוחות שלא משלמים... מי המשוגע שהמציא את השוטף + 120 ?״

״איך אפשר לעבוד ככה עם כל הפגישות האלה?!״

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

״אני מתמחר לפי פיצ׳רים לא לפי שעות, ומכניס את שעות כתיבת הבדיקות לעלות של הפיצ'ר.״

״אני לא בונה אתרי וורדפרס״

״מדיניות התשלום אצלנו היא נט + 30 ואני עובד רק עם לקוחות ששילמו מקדמה״

״כל פגישה עם הלקוח מחויבת בתשלום של שעת ייעוץ כולל פגישות היכרות עם לקוחות חדשים״.

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

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

.item {
    transition: all 0.5s;
}

.close {
    height: 0;
    overflow: hidden;
}

.open {
    height: auto;
}

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

הלכתי לחבר Stack Overflow לראות מה ההמלצות וכמובן שאני לא הראשון שניסיתי את זה. ההצעה שם היתה להשתמש בגובה מקסימלי כדי לייצר את האנימציה: כלומר תגדירו גובה מקסימלי 0 במצב סגור וגובה מקסימלי ממש גבוה למצב פתוח וכך נקבל אנימציה על ה max-height. הגובה האמיתי נקבע ל auto והכל (כמעט) יעבוד:

.item {
    transition: all 0.5s;
}

.close {
    max-height: 0;
    overflow: hidden;
}

.open {
    max-height: 1000px;
}

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

בקיצור ביקשנו אנימציה של חצי שניה אבל בפועל היא הסתיימה הרבה יותר מהר.

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

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

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

גם אני.

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

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

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

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

https://keithclark.co.uk/articles/pure-css-parallax-websites/demo3/

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

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

http://inbalgeffen.com

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

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

http://www.hasadna.org.il

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

רעיונות נוספים? מוזמנים לשתף בתגובות.

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

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

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

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

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

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

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