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

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

1. האקר זדוני מקלקל שורה בקובץ ועושה קומיט.

2. חבר טוב בטעות מוחק את הקובץ כי משהו שם נראה חשוד.

3. החבר מיד מבין שטעה והקובץ דווקא היה חשוב, אז מפעיל revert כדי להחזיר את הקובץ.

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

הנה הכל בהמחשה על מאגר לדוגמא. המאגר כרגע כולל רק קובץ אחד בשם demo.txt:

$ git log --oneline
193c20a (HEAD -> master) initial commit

$ ls
demo.txt

$ cat demo.txt
hello
this is a demo file
created by mr. nice guy

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

# now evil hacker arrives
$ sed -i .bak 's/mr. nice guy/evil hacker/' demo.txt
$ rm demo.txt.bak
$ git commit -a -m 'hahaha'

$ git log --oneline
c4a9b1b (HEAD -> master) hahaha
193c20a initial commit

ואחרי זמן מה חבר נחמד בטעות מוחק את הקובץ ומחזיר אותו עם revert:

$ git rm demo.txt
$ git commit -m 'oops'
$ git revert HEAD
$ git log --oneline

5bc7d72 (HEAD -> master) Revert "oops"
0f96ad4 oops
c4a9b1b hahaha
193c20a initial commit

כשננסה להפעיל git blame על הקובץ נגלה להפתעתנו שמי שכתב את השורה האחרונה הוא החבר שלנו בקומיט האחרון:

$ git blame demo.txt
5bc7d722 (ynonp 2019-07-07 15:24:36 +0300 1) hello
5bc7d722 (ynonp 2019-07-07 15:24:36 +0300 2) this is a demo file
5bc7d722 (ynonp 2019-07-07 15:24:36 +0300 3) created by evil hacker

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

אני רוצה לדלג על 5bc7d722 אז אעביר את זה שלפניו:

$ git blame 5bc7d72~ demo.txt
fatal: no such path demo.txt in 5bc7d72~

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

$ git blame 5bc7d72~~ demo.txt
^193c20a (ynonp 2019-07-07 15:20:43 +0300 1) hello
^193c20a (ynonp 2019-07-07 15:20:43 +0300 2) this is a demo file
c4a9b1b5 (ynonp 2019-07-07 15:23:06 +0300 3) created by evil hacker

וכך מגלים שהקומיט הבעייתי הוא c4a9b1b5.

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

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

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

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

וכמו שתשובות יכולות להופיע בשפה שאנחנו לא מכירים הן גם יכולות להופיע בטכנולוגיה שאנחנו לא מכירים. אנחנו מחפשים פיתרון לבעיה ב Python2 וכל התשובות באינטרנט מראות את הפיתרון ב Python3. אנחנו מחפשים תשובה לבעיה ב React וכל מה שמצליחים למצוא זה פיתרון ב jQuery לאותה בעיה.

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

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

ואחרי 8 שנים של פרילאנס אני כבר יודע להגיד שזה הפחד הלא נכון.

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

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

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

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

ב Express בשביל להגן על האתר שלכם ממתקפת CSRF אתם תצטרכו:

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

2. להתקין את הספריה.

3. להיזכר שאתם צריכים להגן גם על ה API שלכם ולמצוא את הספריה cors-gate, ואז להתקין גם אותה.

4. להפעיל את שתי הספריות לפי ההוראות בתיעוד שלהן באמצעות הוספת Middlewares.

5. להוסיף בכל אחד מהטפסים במערכת את ה CSRF Token.

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

בריילס כל זה קורה אוטומטי בשבילכם ומופעל By Default בכל פרויקט חדש.

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

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

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

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

״אני כבר יודע פרל, אין צורך ללמוד פייתון״

״אני כבר יודע jQuery, אין צורך ללמוד ריאקט״

״אני כבר יודע SQL, בשביל מה אני צריך ללמוד Mongo?״

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

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

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

״אני כבר יודע פרל, עכשיו זה זמן מעולה להתחיל ללמוד פייתון״

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

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

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

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

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

אבל לפרלאנסריות (ופרילאנסרים) זה לא עובד ככה.

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

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