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

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

הספריה emotion.js מספקת תחביר מהיר ונוח למימוש CSS In JavaScript. אם תהיתם מה זה אומר או איך זה נראה הגעתם למקום הנכון. אבל לפני הכל למה זה טוב.

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

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

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

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

האמת היא שבתוך התעשיה כולם מבינים (גם אם זה לא תמיד עובר החוצה) שכשאנשים מדברים על מחסור במתכנתים מתכוונים למחסור במתכנתים כוכבים, ב-10% או 5% של מתכנתים הכי טובים בארץ שעליהם כולם רבים. יש הרבה יותר משרות לא מאוישות ממתכנתים כוכבים, וזה ברור.

הנה ציטוט של שחר בר-אור, מנהל הפיתוח של ווסטרן דיגיטל בארץ מראיון שנתן לדה מרקר:

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

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

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

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

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

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

שנה טובה ינון

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

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

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

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

evenings_ok=(
"Pesach I"
"Pesach VIII"
"Shavuot I"
"Tish'a B'Av"
"Rosh Hashana II"
"Yom Kippur"
"Sukkot I"
"Shmini Atzeret"
)

no_emails=(
"Rosh Hashana"
)

for send_in_evening in "${evenings_ok[@]}"
do
    # echo "^[0-9/]+ ${send_in_evening}"
    if hebcal $(date +"%d %m %Y") | egrep "^[0-9/]+ ${send_in_evening}" >& /dev/null
    then
        if (( $(date +%"H") < 20 ))
        then
            exit 1
        fi
    fi
done

for holiday in "${no_emails[@]}"
do
    if hebcal $(date +"%d %m %Y") | egrep "^${holiday}" >& /dev/null
    then
        exit 1
    fi
done

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

שנה טובה ינון

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

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

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

שני הטיפים שלי להיום אם כך:

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

2. עדכנו את הגדרות ה DNS ברשת הארגונית כך שכשמנסים לגלוש ל ynet או facebook מגיעים לרשימת המשימות הקלות. משהו כמו Captive Portal שמופיע לפעמים ברשתות ומחייב אתכם להסכים לתנאי שימוש כלשהם כדי שתוכלו להגיע לאינטרנט. אפשר להשאיר כפתור קטן שאומר "עזבו אותי ממשימות עכשיו אני רוצה להמשיך לפייסבוק". אפשר גם לא.

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

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

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

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

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

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

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

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

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

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

https://www.tocode.co.il/bundles/git

נתראה שם, ינון

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

$ git log --oneline -10

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

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

1. היא מסבירה מה השינוי שבוצע
2. היא מסבירה למה ביצענו את השינוי
3. היא לא מבלבלת

נתחיל עם הסעיף השלישי כי אותו הכי קל להבין.