מבוא ראשוני לשפת Go - חלק ב' (מבנים בסיסיים, וקצת סגנון)

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

לולאות

1. פקודת for יכולה להכיל תנאי בינארי יחיד - ואז היא מתנהגת כמו while בשפת ג'אווה. ניתן להשמיט את התנאי בכלל - על מנת לקבל התנהגות "while true".
2. הצורה הקלאסית - גם היא נתמכת. אין צורך בסוגריים.
3. ניתן להשתמש בצורה הקלאסית עם השמה מרובה. הלופ הוא על המשתנה x, אך במקביל אנו מקדמים גם את הערך של משתנה y.
4. בלולאת for ניתן להשתמש ב break ו continue בדומה לג'אווה. שימו לב שאין צורך בסוגריים מסביב לתנאי ה if, אך יש צורך בסוגריים מסולסלים לתוצאת התנאי (אפילו אם זה ביטוי קצר). אני בעד!
1. אם יש לנו לופ מקונן, ניתן להגדיר Label ואז לציין בפקודת ה break - את הרמה אליה אנו רוצים לעשות break.
5.  במקום להשתמש בהשמה מרובה - השתמשתי כאן ב map (המקבילה של <?,?>HashMap). הטיפוס שבסוגריים מבטא את טיפוס ה key, והטיפוס אחריו - את טיפוס ה value.
6. השתמשתי ב range על מנת "לטייל" על ה map. אני מעוניין רק ב values ולא ב key, אז שלחתי את ה key ל bulk identifier.
7. שימו לב: הפקודה range תטייל על ה map בסדר מעט אקראי. זהו פיצ'ר של השפה שנועד להזכיר לנו של Map (או Dictionary)  - אין באמת סדר.

פונקציות

1. הגדרת הפונקציה main, שכבר מוכרת לנו. בשפת גו אין ל main פרמטרים או ערך החזרה (כמו ב C, או ג'אווה).
   המילה השמורה להגדרת פונקציה היא func. לא עוד function ארוך או def בפייטון שנשמע כמו "death". אהבתי! חבל שלא קיצרו עוד יותר וקראו לה fun...
2. לפונקציה יכול להיות ערך החזרה, הוא מוגדר מימין.
   למה מימין? האם זה לא קצת מוזר? הסיבה היא עבור מקרים בהם חתימת הפונקציה היא מורכבת:
1. הנה תראו את הפונקציה שמקבלת כפרמטרים "פונקציה שמקבלת 2 ints ומחזירה int" ו int, ומחזירה "פונקציה שמקבלת 2 ints ומחזירה int". לוגי, וקריא בצורה מפתיעה - לא?
2. הנה דוגמה שלילית בה הגדרנו את טיפוס ההחזרה בהתחלה (נניח, כמו בג'אווה). האם אתם מסוגלים לקרוא את זה בלי מאמץ ניכר?
3. הפונקציה יכולה לקבל כמובן כמה פרמטרים. אם הם מאותו טיפוס - ניתן לקצר.
4. ניתן לכתוב גם בכתיבה מלאה. float32 הוא 32 ביט - כך שלא צריך להיזכר כל פעם מהו "double".
5. ניתן להחזיר מפונקציה מספר ערכים. במידה ויש יותר מערך החזרה אחד - יש לשים את ערכי ההחזרה בסוגריים.
6. ניתן לתת שמות לערכי ההחזרה (למשל s1, s2). השמות הללו יוגדרו כמשתנים בפונקציה ולכן אינם יכולים לחפוף לשמות הפרמטרים. הגדרת שמות לערכי ההחזרה מאפשרת לנו להשתמש ב naked return שמחזיר את ערכי המשתנים הרלוונטיים. שימוש אפשרי הוא ערך שאפשר לקבוע בכל מקום בפונקציה, ולעשות return בלי לציין אותו במפורש (למשל error, אבל לא רק).
   הערה: השמות היא שימושיים רק ב scope של הפונקציה, ולא כערך החזרה / חתימה של הפונקציה.
7. פונקציה שמקבלת מספר לא מוגבל של פרמטרים נקראת variadic function. המשתנה שיכיל את "שאר הפרמטרים" מוגדר ע"י שלוש נקודות והטיפוס הרצוי (כמו varargs בשפת ג'אווה). בפועל זה יהיה slice של אותו הטיפוס (מייד נגדיר לעומק מהו slice), והוא חייב להיות הפרמטר האחרון בחתימה הפונקציה - כמובן.

ערכים בגו תמיד מועברים לפונקציה by value (כלומר: כעותק של הנתון). אם רוצים להעביר משתנה by reference - יש להשתמש בפויינטר (& בכדי לקבל פויינטר מערך, ו * בכדי להתייחס לערך שהפויינטר מייצג - כמו בשפת C).

פרימיטיביים מספריים בשפת גו

מערכים ו Slices

מערכים שפת Go הם כמו שאנו מכירים אותם משפת ג'אווה: הם מוגדרים לטיפוס מסוים (מערך של int, מערך של Person) ואורכם הוא קבוע. האיברים ממוינים ע"פ אינדקס שמתחיל ב 0.

Slices הם יותר כמו ArrayList - ניתן דינאמית להוסיף / להסיר איברים מהם.
כמו בשפת ג'אווה - Slices ממומשים על גבי מערך. בעצם ה slice הוא כמו View על ה Array:

מקור: הספר החינמי Build web application with Golang

מבנה הנתונים של Slice מכיל בעצמו:

• שם
• מצביע למערך
• טיפוס האובייקטים במערך
• offset
• length של ה slice

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

אם אתם זוכרים - כל הערכים מועברים בשפת גו by value. אם אתם רוצים להעביר reference - עליכם להעביר פויינטר.

Slices הם סוג של פויינטר. ההעתקה שלהם היא זולה (זה struct קטן עם 5 שדות) ולכן ניתן להעביר אותם בקלות "by value", אבל לקבל התנהגות, על מערך הנתונים, של העברה "by reference". שינוי של ערך ב Slice ישנה כמובן את הערך במערך - בו שמורים הנתונים. ניתן להחזיק כמה slices על גבי אותו המערך, כך ששינוי ערך ב slice אחד ישפיע על ערכים של slices אחרים מעל אותו המערך.

בואו נראה קצת קוד:

1. הדרך ה"פורמלית" להגדיר slice הוא בעזרת פקודת make (המייצרת עוד כמה מבנים בשפת גו). הפרמטרים שאנו שולחים הם:
1. טיפוס - כדי ליצור slice עלינו לציין "מערך" של טיפוס, במקרה שלנו int[].
2. length - אורך ה Slice שאנו רוצים לייצר.
3. Capacity - אורך המערך שגו תייצר, מאחורי הקלעים, עבור ה slice. ה slice לא יכול לחיות ללא מערך מאחוריו, כמו ש ArrayList או Vector לא יכולים לחיות ללא מערך (למי שמכיר את המימוש).
2. אנו בודקים את תוצר היצירה שלנו
1. len היא פקודה בשפה שבודקת אורך של מבנה, במקרה הזה ה slince
2. cap (קיצור של capacity) היא פקודה בשפה שבודקת את אורך התכולה השל המבנה - במקרה שלנו: אורך המערך.
3. צורת הגדרה אחרת היא ה slice literal.
   תחביר ההגדרה דומה מאוד להגדרה של מערך, ההבדל הוא שבהגדרה של מערך עלינו לציין בסוגריים את מספר האיברים (או אפשר פשוט לכתוב שלוש נקודות ...)
4. במקרה זה גו ייצור מערך בדיוק באורך של ה slice (כלומר: 5 איברים).
5. כעת אנו מבצעים פעולת slice על ה slice שלנו. נזכיר שהאינדקס לפני ה סימן : בפעולה - הוא איבר שייכלל ב slice שייווצר, והאינדקס שלאחר סימן ה : - לא ייכלל ב slice שייווצר.
6. התוצאה יכולה לרגע מעט להפתיע - אך היא הגיונית: הנה תרשים שיסביר אותה:

האורך של sliceOfSlice הוא אכן 3. ה capacity שלו הוא 4 מכיוון שיש לו עוד תא אחד לגדול במערך.

הוספת איברים ל slice

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

1. אנו יוצרים מערך של int בגודל 4, ומאתחלים אותו בערכים (השמה מרובה). יכולתי להשתמש בתחביר של array literal, אך מכיוון שהוא דומה כ"כ ל slice literal בחרתי בצורה המגושמת, אך המפורשת יותר.
2. מתוך המערך, אנו מבצעים פעולת גזירה - שיוצרת את slice. להזכיר: האינדקס הראשון כלול, והאינדקס השני לא. תחביר מקוצר לפעולה היה יכול להיות [2:]
3. כפי שאנו רואים slice הוא בגודל 2, וה capacity שלו הוא 4 - בגלל המערך שעליו הוא מבוסס.
4. אם אנו מציבים ערך במערך - הוא משתקף מיד ב slice. המערך הוא האחסון של ה slice.
5. כאשר אנו מוסיפים איבר ל slice, היכן הוא יאוחסן? - במערך, כל עוד הוא גדול מספיק.
   המשמעות היא שאנו דורסים את הערך הישן (100) בערך שנוסף ל slice. בעבודה עם מספר slices מעל אותו מערך - יש סכנה של דריסת ערכים הדדית.
6. הנה אני מדפיס את מצב המערך. v% הוא הסימן להציג את הטיפוס בפורמט ברירת-המחדל שלו. זו תצוגה טובה לצורך debugging.
7. ה slice כרגע בגודל 3 ו capacity של 4. מה יקרה אם נוסיף ל slice שני איברים, מערך ל capacity הנתון?
   הפעולה מצליחה, ואנו רואים שה capacity קפץ ל 8 (כמו Vector ב ++C, ג'אווה, וכו' - מגדילים את שטח האחסון פי 2).
8. כפי שאנו רואים ה slice גדל, אך לא המערך. מערך איננו יכול לגדול - בהגדרה.
   פקודת append הגדירה מערך חדש גדול פי 2, והעתיקה אליו את כל הערכים הקיימים. הקשר בין slice ל array ניתק - ו slice עכשיו מצביע (ומאחסן נתונים) במערך חדש שהוקצה עבורו.
9. הנה וידוא נוסף, שזה אכן מה שהתרחש: אנו מציבים ערך ב array - ורואים שהוא לא השפיע על הערך ב slice.

כפי שאתם רואים, ה slice מכסה לנו את ההתנהגות הכל-כך נדרשת של ArrayList.

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

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

איך מסירים איבר מ slice? הרי המערך הוא קבוע ורציף בזיכרון... הנה דוגמה:

1. הדרך להסיר איברים היא בעצם ליצור slice חדש, שיכיל פחות איברים.
   התחביר של ... הוא expansion שהופך את ה slice לרשימה של פרמטרים - הצורה לה הפונקציה append מצפה.
2. אנו יכולים לראות שהפעולה הצליחה והמספר 10 נמחק מהרשימה.
   מדוע, אם כן, ל slice יש capacity של 4?
3. בגלל שפקודת append לא יצרה מערך חדש. היא בכלל לא מודעת לזה שביצענו מחיקה.
   כמו שראינו את הדוגמה הקודמת - הוספה של איבר ל slice מוסיף את הערך במקום הבא במערך - אם יש מקום לכך.

Structs

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

אפשר לחשוב על Struct כאובייקט ללא מתודות - רק members.

1. אנו מגדירים struct חדש בעזרת המילים השמורות type ו struct. בניגוד לג'אווה או #C בהם מקובל ששם של טיפוס (מחלקה, struct ב #C) מתחיל באות גדולה, בשפת גו האות הגדולה מציינת האם הטיפוס הוא פרטי לחבילה (אות קטנה) או ציבורי (אות גדולה)
1. בתוך ה struct אנו מגדירים את השדות (נקראים fields).
2. יש לנו 3 דרכים ליצור instance חדש של ה struct שהגדרנו
1. ע״י שימוש ב var - ה struct יאותחל לערכי 0.
   שפת גו לא מגדירה אם בצורה זו האובייקט ייווצר על ה stack או על ה heap - זה פרט מימוש של הקומפיילר. בד״כ הקומפיילר יבצע תהליך שנקרא escape analysis ויראה אם יש חובה להגדיר את המופע, במקרה הספציפי, על ה heap. העדפת ברירת המחדל היא להגדיר אובייקטים על ה stack (מכיוון ששחרור הזיכרון הוא אפקטיבי יותר).
2. ע״י שימוש במילה השמורה new, שיגרום ל:
1. האובייקט ייווצר על ה heap. כל הערכים יאותחלו לערכי אפס.
2. המשתנה sprite2 יכיל פויינטר לאובייקט, ולא את האובייקט עצמו.
3. ע״י צורת ה shorthand של יצירה והשמת ערכים. בצורה זו אנו מציבים ערכים בעצמנו. כמו צורה #1 - אין הבטחה אם האובייקט ייווצר על ה stack או ה heap.

כמה מלים על קונבנציית השמות בשפה:

• שם חבילה (package) משמש כ namespace דרכו ניגשים לאלמנטים בחבילה. על כן חשוב שזה יהיה שם קצר וברור. מקובל ששם לחבילה היא מילה בודדת באותיות קטנות, למשל "strings".
• כנ"ל לגבי שמות התיקיות המכילות את החבילה.
• הנה פרויקט של ה NYTimes שהחליטו לשבור את הכלל הזה - פשוט כי קשה להם לקרוא את השם כ nytimes. הם לא רגילים. כל כלל ניתן לשבירה, אם מוכנים לשלם את המחיר (כרגע זה מציף כמה מקרי קצה ב tooling של go).
• שלפנים (Getters/Setters) - אלו לא כ"כ מקובלים בשפה, אך אם אתם משתמשים בהם - עליהם להיות כשם ה filed עם אות ראשונה גדולה. 
• השדה: user (אות ראשונה קטנה = פרטי לחבילה)
• השלפן: User (אות ראשונה גדולה = ציבורי)
• כל הטיפוסים / משתנים האחרים הם ב MixedCaps, שזו צורה כמו CamelCase, עם ההחרגה שהאות הראשונה מציינת את הנראות.
• טיפוס/משתנה פרטי בחבילה: myUniqueType
• טיפוס/משתנה ציבורי: MyUniqueType
• ממשקים (interfaces) עם מתודה יחידה יקראו כמו שם המתודה, עם er של "התמחות":
• ממשק Reader המכיל את המתודה Read.
• ממשק Shopper המכיל את המתודה Shop.
• לא הוגדר, אך אני הייתי קורא לממשק עם מתודה יחידה ReadString בשם StringReader.
• אפשר למצוא עוד פירוט על ההגדרות הללו ב Effective Go.

Gopher עם סטייל - מקור

עניין של סגנון

אז איך סגנון הכתיבה "הנכון" או "המקובל" בשפת Go?

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

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

• הקומפיילר ו gofmt (שאני מקווה שרוב ה IDEs עובדים איתה) - מכתיבים חלק גדול מהסגנון. רוצים סוגריים מסולסלים בשורה חדשה? - אין.
• שפת Go היא מינימליסטית: אין Generics, ואין Meta-programming - כלים שלרוב הם הבסיס ליצירת סגנונות בשפה (ע"י Frameworks, בד"כ). אין הורשה, אין מחלקות מקוננות, אין מחלקות אבסטרקטיות. בעצם: אין מחלקות. כל אלו, כלים שעוזרים להגדיר "DSL" על גבי השפה - ואין אותם ב Go.
• הספריות הסטנדרטיות של שפת גו מכסות מרחב גדול של נושאים, שלרוב מגיעים כספריות צד-שלישי: בדיקות (יחידה/אינטגרציה/APIs, ועוד), Templating, עבודה עם HTTP, שרת ווב, טיפול ב JSON/XML, ועוד.
  ספריות, ובעצם ה APIs שלהם - נוטים להכתיב חלק גדול מהסגנון הכתיבה שלנו. אם כולם משתמשים באותן ספריות - הקוד הוא יפה.

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


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

1. נהוג להשתמש בתחביר של if עם השמה מרובה, ובדיקת שגיאה  -באותה השורה. לרוב עבור טיפול בשגיאות.
2. מה שלא נהוג לעשות הוא להיכנס לקינון של if או בלוקים מסוג אחר. יש הרבה מפתחי ג'אווה שכותבים כך קוד - אז זה מצב לא רצוי ב Go.
3. מה שיש לחתור אליו הוא להישאר, עד כמה שאפשר, ברמת אינדנטציה מינימלית. זה אומר:
1. לפצל פונקציות לפונקציות קטנות יותר.
2. במקרה לעיל (#2) הסיבה לכתוב קוד בתוך ה else היה ה scope בו הוגדר המשתנה err. אין בעיה: ניתן להגדיר אותו ב scope רחב יותר - ואז להיפטר מהאינדנטציה הנוספת.
3. עוד דבר שמצמצם את כמות שורות הקוד באינדנטציה במשפטי if הוא, לטפל קודם במקרה הפשוט (במקרה שלנו: return x - שורה אחת באינדנטציה), ואז במקרה המורכב יותר - מחוץ ל if (במקרה שלנו: הטיפול בשגיאה - 4 שורות שעכשיו אינן באינדנטציה).

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

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

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

עוד כמה נקודות קצרות:

• מתכנתי Go אוהבים לכתוב בדיקות-יחידה, והרבה!
• עושים הבחנה ברורה בין בדיקות יחידה (שם הפונקציה מתחיל ב Test), בדיקות ביצועים (שם הפונקציה מתחיל ב Benchmark) ובדיקות קבלה / לצורך תיעוד (שם הפונקציה מתחיל ב Example).
• עדיף להשתמש ב switch ולא ב if else if.
• אני במקור דווקא מחבב את if else if, אבל ב Go אין צורך ב break - אנסה באמת לזרום עם מה שמקובל.
• עדיף להחזיר כמה ערכים מפונקציה, ולא להשתמש בפרמטר שהוא pointer כ "out value" (כמו שמקובל ב #C).

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

סיכום קצר

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


שיהיה בהצלחה!



----


לינקים רלוונטיים


Slice Tricks in Go - לא ממש טריקים, אלא ריכוז הפעולות השונות על slices.

Best practices for a new Go developer - המלצות משורה של מתכנתים מנוסים ב Go, על מה כדאי לשים לב כשנכנסים לשפה. דוגמאות:

• אנשים חדשים נוטים לעשות overuse למודל ה concurrency של Go (כי הוא "כ'כ מגניב"?!).
• נסו להתמקד ולהבין את מודל ה interfaces לעומק - זה לב השפה (רלוונטי למי שלא הגיע מג'אווה או #C).
• השתמשו ב gofmt, כהרגל - כבר מההתחלה.

twelve Go best practices - גם נחמד

50 גוונים של Go - טעויות נפוצות של מתכנתים מתחילים בגו. מקום טוב ללמוד ממנו "פינות" של השפה.

Code Review Comments - מדריך לכתיבת הערות בגו

ברומא, התנהג כרומאי, Organizing Go Code, שפת גו - ל Gophers  - מצגות טובות על סגנון כתיבה מקובל בגו.

מבוא ראשוני לשפת Go, למפתחים ותיקים

בחברת Gett אנו מתחילים לאחרונה לעבוד יותר ויותר עם שפת Go (לחיפוש בגוגל, חפשו: "golang" [א]).

מדוע דווקא Go?

בסיבוב הראשון (עוד מזמן) היה לנו קטע קוד ברובי - שלא רץ בצורה מספיק יעילה. ארגנו בחברה תחרות בין node.js ו elixir ו-2 מפתחים מימשו את הקוד בשפות הנ"ל. קוד ה node.js היה יעיל יותר - וזכה, אך לאורך השבועות הבאים גרם ל memory leaks שלא הצליחו לפתור. מתכנת שלישי עשה את אותו התרגיל בשפת Go - והקוד אכן היה מהיר ויציב.

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

לפני שהמשכנו להתקדם עם Go (ולהשקיע בה), שאלנו את עצמנו את השאלה: האם באמת Go היא השפה איתה אנו רוצים להתקדם? האם בחרנו אותה בהליך סביר?!

בחנו עוד אופציות: מ JRuby, סקאלה, דרך Groovy, node.js (שמקלה על המעבר מרובי) ועד Java8.
המועמדות הסופיות היו Go ו Java8.

• שתי השפות יכולות להתמודד עם ה throughput הגבוה שנדרש לנו. 
• בשתיהן יהיה על רוב המתכנתים אצלנו ללמוד שפה (יותר מזה: סביבת-ריצה) חדשה.
• לשפת ג'אווה (החלק החשוב: ה JVM) יש הרבה יותר כלים, בשלים ומוכרים. שפת Go היא עוד מתפתחת. למשל: אין לה עדיין ספריה סטנדרטית ל New Relic, וה SDK של AWS שוחרר רק לפני כחודש.
• בשפת Go היה לנו הרבה פחות דילמות לגבי Frameworks. השפה וגם הספריות / Frameworks הזמינים בה הם דיי Low Level ושקופים למשתמש - מה שמגביר ומשפר את הלמידה. (את דעתי בנושא אפשר ללמוד בפוסט: מהו ה Framework הטוב ביותר)

חלק מהמפתחים שהתייעצנו איתם לא הרגישו נוח עם השימוש ב Java8. הרתיעה משפת ג'אווה הוא דבר נפוץ למדי בקהילת הרובי - קשה לי להסביר בדיוק למה.

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

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


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

הלוגו של שפת Go - ה Gopher (סנאי ערבה). אין קשר לפרוטוקול Gopher (המתחרה הקדום של FTP).
gopher הוא גם כינוי למתכנת Go.

הצצה ראשונית לשפת Go

מה יותר טוב מלראות מעט קוד?

הקוד (הפשוט) הזה הוא web server מינימלי שמחזיר את הטקסט "!Hello world".

1. הגדרה של package בתוכנית שלנו.
   הקונבנציה לשמות של package בשפת Go היא מילה בודדת ב lowercase, וללא קווים תחתונים. שם החבילה (package) אמור להתאים לשם התיקייה בו הקובץ נמצא.
   אזהרה: אם לא תעקבו אחר כללים אלו, התוכנית עלולה לא להתקמפל, וללא אזהרות מיוחדות [ב].
2. אנחנו מייבאים 2 חבילות סטנדרטיות של Go: לטיפול ב I/O (כללי), וטיפול ברשת.
   התחביר של הסוגריים (שמייתר את הצורך בפסיק או נקודה פסיק) נקרא Grouping Declaration.
3. פונקציית main היא זו שממנה התוכנה מתחילה לפעול. עליה להיות שייכת גם לחבילה בשם "main".
4. קריאה למתודה HandleFunc רושמת כניסה חדשה ב DefaultServeMux.
   Mux, בטרמינולוגיה של Go היא כמו Router ב MVC: אובייקט שתפקידו למען בקשה לאובייקט (במקרה שלנו: פונקציה) הנכונה שתטפל בה.
   אנו רושמים את ה default path (כלומר: "/") למתודה sayHello.
5. המתודה ListenAndServe מפעילה את "שרת הווב" של Go, ורושמת אותו ל Port ו Mux.
   מכיוון שלא ציינו Mux (ה nil) - יעשה שימוש ב DefaultServeMux.
6. הפונקציה sayHello היא פונקציה פשוטה. עצם כך שהאות הראשונה בשמה היא אות lowercase גורם לפונקציה להיות private. ליתר דיוק: להיות זמינה רק באותה החבילה, כמו default visibility בשפת ג'אווה.
   מתודה או טיפוס שמתחיל באות גדולה הוא "exported" - כלומר זמין לחבילות אחרות (כמו public בג'אווה).
7. אנו רואים שאנו מקבלים את הפרמטר מסוג http.Request כפויינטר (מצביע). פויינטר הוא הדרך להעביר אובייקט by reference - אך אין "pointer calculus" כמו בשפת C. כלומר: לא מבצעים פעולות חשבוניות על הכתובת שבפויינטר.
8. המתודה io.WriteString מבצעת כתיבה של slice of bytes ל Writer.
   לשם הפשטות, נסתפק כרגע בידיעה שמחרוזת בשפת Go היא slice of bytes שהוא read-only.
   slice הוא מערך, או חלק ממערך - אכסה את הנושא של slices בפוסט המשך.

כאשר אקמפל את התוכנית אראה שנוצר קובץ בינארי של בערך 6MB.

6MB? זה לא קצת הרבה לעשר שורות קוד?

כאשר אני מצמצם את התוכנית ל ("print("hello, הקובץ קטן - אך הוא עדיין בגודל של 2MB.

הסיבה לכך היא שיש לנו static linking. הקובץ כולל את כל הספריות להן הקוד זקוק + את סביבת ה runtime של Go.

להעביר קובץ של 6MB לשרת (או אפילו 60MB) זו לא בעיה גדולה היום.

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

אפיון שפת Go

במשפט אחד: Go היא הרכבה בין ++C ל Python.

בשני משפטים: Go היא שפת System ו General Purpose ששואבת מרכיבים מכמה שפות, בעיקר C ו Python. היא סטטית כמו C, אבל כוללת ספריות וקיצורים בשפה (כמו השמה מרובה) המקובלים ב Python - שהיא שפה "גבוהה".


מכנה משותף בין Go לג'אווה:

• תחביר של C-Syntax
• Statically Typed
• יש Garbage collector
• memory-safe - אי אפשר לדרוס זכרון של קטע קוד אחר (כמו ב C), מצד שני יש null.
• יש interfaces וניתן לזהות אותם בעזרת instanceof.
• יש Reflection

יש דברים שונים:

• הקוד בגו מתקמפל ישר ל Machine code, ולא ל "bytecode".
• יש static linking של ספריות (כלומר: לקובץ הבינארי - כמו ++C) ולא dynamic linking (טוענים jar. בצורה דינאמית).
• יש שימוש ב pointers (אבל לא תכוף ומשמעותי כמו בשפת C).
• בגו יש מודל Concurrency מפותח יותר מג'אווה, שהוא חלק מהשפה.
• הספריות ה default שמגיעות עם השפה, מקיפות סט שימוש רחב יותר (בדיקות, עבודה עם json, תכנות ווב, וכו') מאלו של ג'אווה. זה דיי מפתיע, כי גם לג'אווה יש סט עשיר למדי של ספריות.

בכדי לשמור על השפה פשוטה, וויתרו במתכוון על כמה תכונות של שפה:

• אין מחלקות (אלא Structs עם מתודות "מקושרות")
• אין בנאים (constructors) - משתמשים במקום ב Factory methods
• אין הורשה (לא יחידה, לא מרובה)
• אין exceptions
• אין annotations
• אין Generics (לפחות לא כאלו שהמתכנת יכול להגדיר).
• יש צמצום בכלים של השפה, שיש להם תחליף (למשל יש for, אבל אין while...until).

אלמנטים משותפים בין שפת Go ושפת Python:

• שפה פשוטה ומינימליסטית.
• השפעות רבות בתחביר: func במקום def (אבל מרגיש אותו הדבר), מבני נתונים כחלק מהשפה, השמה מרובה, slicing, ממשקים כ Duck Typing ("אם הוא עושה קול של ברווז, והולך כמו ברווז - אז הוא ברווז"), ועוד.
• "יש דרך אחת מומלצת לעשות דברים" - Go היא שפה מאוד opinionated, יותר מפייטון - וההיפך הגמור משפת רובי.
  למשל: הדילמה האם לפתוח סוגריים מסולסלים בשורה קיימת או חדשה - נפתרת במהירות ע"י הקומפיילר: סוגריים מסולסלים בשורה חדשה זו שגיאת קומפילציה!
• גישה זה עלולה להישמע קיצונית בהתחלה, אך בסופו של דבר, כשהמערכת מתחילה להגיע לבגרות, רבים מאוד מאיתנו משתמשים בכלים של Static code analysis בכדי למנוע מעצמנו שונויות של סגנונות בקוד. אפשר לראות בזה כלי static analysis שמוטמע כבר בקומפיילר.
• יש לציין ששפת Go היא יותר verbose מ Python. יש לכתוב יותר קוד בכדי להשיג תוצאה דומה.

מבנה תיקיות של פרוייקט בשפת Go

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

• GOROOT - המצביע לתיקיה בה נמצא ה GO SDK
• GOPATH - המצביע למקום בו נמצא קוד ה GO.

רוב הניסיונות להתחכם, ולנהל קוד Go בתיקיות שונות במערכת - יסתיימו באכזבה (שלכם). הדרך היחידה המקובלת, שאני מכיר, לנהל את הקוד בתיקיות שונות הוא לייצר symbolic links תחת GOPATH לתיקיות בהן אתם רוצים לנהל את הקוד.

GOPATH יכול להיות גם תיקיית המשתמש (~).

תחת התיקייה GOPATH ישנן 3 תיקיות:

• src - התיקייה מתחתיה נמצא הקוד שלכם.
• pkg - התיקייה מתחתיה נמצאים package objects שמתארים את הקוד מצב הקוד המקומפל (כך שלא צריך לקמפל בשנית). כל צמד "מערכת הפעלה"_"ארכיטקטורת מעבד" מנוהל בתיקיה משלו.
• bin - התיקייה אליה נשלחים תוצרי הקומפליציה (קבצים בינאריים). הקומפילציה עצמה מתרחשת בתיקיה tmp של מערכת ההפעלה (התיקיה המדוייקת - תלוי במערכת ההפעלה).

תחת תיקיית ה src ניתן לשים packages ישירות, אך יותר מקובל לנהל תיקיות לכל פרוייקט ("workspaces") ורק מתחתיהן התיקיות של ה packages:

כאשר נפעיל ב command line את הפקודה go install hello/web/server, הכלי לא ישאל היכן החבילה (package) נמצאת - הוא ימצא אותה בעצמו.

reference רלוונטי

הגדרת משתנים

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

1. בשפת Go, מגדירים משתנה בעזרת המילה השמורה var. קודם מופיע שם המשתנה -  ורק אז הטיפוס (הפוך מ Java או C - מה שמבלבל בהתחלה).
2. ניתן באותה השורה גם לאתחל ערך. אם לא מאתחלים ערך, הקומפיילר של Go יקבע "ערך אפס" (המספר 0 עבור מספר, nil עבור אובייקט, וכו')
3. בהשראת Python - מנסים ב Go לייתר הגדרות לא הכרחיות: אם אנו מציבים ערך ברור (במקרה שלנו: 1 שהוא int) אז הקומפיילר של Go יקבע את הטיפוס בעצמו ע"פ כללים מסוימים (במקרה שלנו: int).
4. ניתן באופן מקוצר לבצע כמה הגדרות של משתנים כ Grouping declaration.
5. בתוך פונקציה, הגדרת משתנה שלא בשימוש (במקרה שלנו: f) - היא שגיאת קומפילציה.
6. בתוך פונקציה, ניתן להשתמש בתחביר מקוצר =: המייתר את השימוש ב var, במידה ואנו מציבים ערך במשתנה.

הנה עוד כמה התנהגויות:

1. ב Go אין casting אוטומטי של טיפוסים. חיבור של int ו float גורר שגיאת קומפילציה. הגישה של Go היא "אנחנו לא רוצים אקראיות - תגדיר בדיוק למה התכוונת". זו גישה מאוד בוגרת - לשפה "צעירה ומגניבה".
2. ניתן לבצע casting בקלות יחסית (הסוגריים הם על המשתנה ולא על הטיפוס - הפוך מג'אווה), ולקבל תוצאות בהתאם.
3. ישנם גם קבועים. הם דומים להגדרת משתנים ב var, אך לא ניתן להשתמש בתחביר המקוצר =:, וכמובן שלא ניתן לדרוס את הערך לאחר שהוגדר. נסיון לדרוס קבוע - מסתיים בשגיאת קומפליציה, כמובן.
4. אם אתם לא מעוניינים להשתמש כרגע במשתנה, אבל גם לא רוצים שגיאת קומפילציה - הציבו את ערך המשתנה בתוך ה blank identifier שהוא קו תחתון. ה blank identifier הוא משתנה לכתיבה בלבד, כאשר רוצים להיפטר מערך כלשהו. ממש כמו dev/null/ בלינוקס.

טיפול בסיסי במחרוזות

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

1. ניתן להגדיר טווח בסוגריים, בכדי לבצוע sub_string מתוך מחרוזת.
2. for ... range הוא ה "foreach" של שפת גו. ניתן להשתמש ב range על מערך, slice (חלק ממערך), מחרוזת, map או channel (קונסטרנט לתקשורת בין goroutines, נגיע אליהן בהמשך).
   range בעצם מחזיר 2 ערכים: key ו value, מה שלא מוצג בדוגמה למעלה (יש שימוש רק ב key, שהוא האינדקס של ה char במחרוזת).
3. ב go יש שימוש נרחב ב Printf, לביצוע הדפסה עם formatting - ממש כמו בשפת C. הפקודה Printf מתחילה באות גדולה - מכיוון שהפונקציה היא public לחבילת "fmt". ניתן לגשת ל character במחרוזת בעזרת אינדקס (כמו שפות רבות אחרות).
4. איזה כיף! יש הגדרה של מחרוזת  multi-line!
   שימו לב ששורה 2 עד 4 יכילו מספר רווחים לפני הטקסט, כי העימוד מתחיל מעמודה 0 ולא מהעימוד של שורת הקוד הקודמת (התנהגות זהה לפייטון, אם אני זוכר נכון).

Result מרובה וטיפול בסיסי בשגיאות

1. הפונקציה Printf מחזירה כתשובה את אורך המחרוזת בבייטים. בנוסף: היא מחזירה שגיאה אם הייתה בעיה בכתיבה (nil במידה ואין שגיאה).
   השמה מרובה נעשית כמו בפייטון, עם פסיק בין הערכים.
2. קוד לדוגמה בו אנו בודקים את השגיאה ומתנהגים בהתאם.
3. הנה כתיבה מקוצרת ומקובלת למדי בשפה: אנו מבצעים את הפעלת הפונקציה וההשמה בתוך משפט ה if התחום בסימן ; (תוחם statement). היא שקולה לסעיפים 1 + 2.

טיפול השגיאות בשפת Go הוא נושא שנוי במחלוקת:
- מצד אחד, האווירה בגו (אפס סובלנות של הקומפיילר למה שעשוי להיות שגיאה) מכוונת את המשתמשים לכיסוי גבוה של טיפול בשגיאות - מה שמוביל לקוד לא כ"כ אסתטי, שחוזר על עצמו ומעט מרגיז.
- מצד שני, גם בשפות כמו #C או ג'אווה שבהן יש מנגנון exceptions - כשהתוכנה מתבגרת, אנו כותבים כמעט אותה כמות של קוד לניתוח ה exceptions. האידאל לפיו "זרוק exception עמוק בפנים, וטפל בו רק ברמת ה UI (כהודעה למשתמש)" - לרוב לא מתממש.

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

יאללה כיף - goroutines

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

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

טיפה רקע תיאורטי:

מודל ה goroutines של שפת גו הוא בעצם מימוש של רעיון שנקרא coroutines: הבסיס ל concurrency הוא פונקציות, ולא "אובייקטים פעילים" (כמו threads).
מודל המקביליות עצמו מתבסס על מודל ה Communicating Sequential Processes  (בקיצור CSP) של טוני אוהרה משנת 1978, שלא היה בשימוש נרחב עד שפת גו הציגה אותו כחלק מהשפה עצמה (ולא כספריה חיצונית).

המודל של Actors, המודל "של סקאלה" (בעצם Akka? או PID של שפת Erlang), הוא פרי עבודתו של קארל הייט מ1973.

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


חזרה לת'כלס:

ה goroutines של שפת גו הם בעצם סוג של Green-threads, נימים (threads) המנוהלים ע"י סביבת הריצה או ה VM - ולא ע"י מערכת ההפעלה.
יתרה מכך: greenthreads לא משתמשים באף מנגנון של מערכת ההפעלה. כל הניהול הוא אפליקטיבי ומתרחש ב user space (ללא context switch ל kernel).

• green threads הם מהירים יותר ליצירה, לתזמון, ולסנכרון. עבודת CPU תהיה לרוב יעילה משמעותית יותר איתם, מאשר עם native threads.
• צריכת הזיכרון של green threads יכולה להיות משמעותית קטנה (בשפת go, ה stack ההתחלתי של goroutine הוא 2KB זכרון, מול 1MB ב thread של מערכת ההפעלה) - מה שמאפשר להחזיק הרבה מאוד goroutines במקביל.
• כאשר מדובר בהרבה פעולות I/O, דווקא native threads נוטים להיות יותר יעילים.
• green threads לא יכולים להשתמש בריבוי מעבדים, וזה כולל את יכולת ה Hyper-Threading של אינטל, שמדמה מעבדים וירטואליים.
• כאשר / אם green thread מבצע פעולת blocking ברמת מערכת ההפעלה (ולא הדמיה שלה סינכרוניות ברמת סביבת הריצה), לא רק ה green thread נחסם - אלא נחסם ה thread של מערכת ההפעלה עד סיום פעולת ה I/O (שכעת לא יכול לתזמן green threads אחרים). לשפת Go ספציפית יש ייתרון שהיא חדשה, ותוכננה לתסריט זה. היא לא מספקת גישה לקריאות blocking I/O (אולי רק ממשק שנראה שכזה) כמו שפות קיימות (למשל ג'אווה) - ולכן זה עניין שהתמכנת לא צריך לדאוג לו.

בואו נראה קצת קוד:

התוכנית שלנו קוראת ל-2 פונקציות: printHello ו printWorld.

1. בשלב זה אנו קוראים ל printWorld, אבל שימו לב למילה השמורה go: היא גורמת לפונקציה הרגילה לגמרי לרוץ כ goroutine על greenthread של סביבת הריצה של גו!
   קרוב לוודאי שיש קשר חזק בין שם השפה - לשם המילה השמורה go.
2. הפונקציה (שרצה ב greenthread נפרד) תמתין עכשיו כ 2 שניות. זה לא יפריע לשאר התוכנית להמשיך ולרוץ.
   לאחר ההמתנה היא תדפיס את הטקסט "!World".
3. בזמן ש printWorld ממתינה, אנו קוראים לפונקציה printHello, גם כ goroutine.
   יכולתי להגדיר את printHello כעוד פונקציה של ה package, אבל חבל לי להעמיס על המרחב הציבורי עבור פונקציה של שורה אחת.
   למה אני זקוק לעוד פונקציה עבור שורת קוד בודדה? כי אני רוצה להריץ אותה כ goroutine, כמובן!
1. שפת גו מאפשרת להגדיר פונקציה ולהריץ אותה מיד, בעזרת כתיבת סוגריים מיד לאחר הגדרת הפונקציה - ממש כמו בשפת javaScript.
   זה התרגיל שעשיתי - ואני מקווה שלא הקשיתי מדי לעקוב (אני גם לא רוצה לשעמם...)
4. פה יש קטע: מכיוון ש printHello ו printWorld רצות במקביל כ goroutines, הפונקציה main הגיעה לסופה - מה שיגרום לתוכנה להסתיים, ולא אוכל לראות את הפלט של התוכנית.
   אני יוצר המתנה יזומה של 3 שניות בפונקציה main (שלצורך העניין היא goroutine בפני עצמה), בכדי לתת דיי זמן ל printHello ו printWorld להתבצע בבטחה.

הפלט של התוכנית יהיה כמובן: "!Hello World" (כאשר המילה השניה מודפסת לאחר כ-2 שניות).

קצת מפריע לי שהייתי צריך להמתין כ 3 שניות שלמות, על פעולה שמסתיימת כנראה לאחר כ 2.000001 שניות, לערך. האם אין דרך נבונה יותר מ Sleep לסנכרן בין goroutines?!

בוודאי שיש:

1. אנו יוצרים אובייקט מסוג WaitGroup שיקרא מעתה "המוניטור" (ע"ש דפוס העיצוב)
2. אנו מודיעים למוניטור שתנאי הסיום שלו הוא 2 הודעות Done.
3. כל אחת מהפונקציות printHello ו printWorld יודיעו למוניטור כשהן סיימו.
   אנו כמובן עושים זאת בדרך של גו: בעזרת המילה השמורה defer - שמבטאת רעיון יפה מאוד:
   התפקיד של defer היא כמו finally בשפת ג'אווה - לבצע דברים בסיום ההרצה של הפונקציה, גם במקרה סיום תקין וגם במקרה של סיום עם שגיאה.
   נקודת חולשה של finally היא שההקשר הסיבתי אבד: כל הפעולות שיש לבצע ביציאה מהפונקציה מרוכזות בבלוק ה finally ללא קשר ממה הן נובעות. הפקודה defer מאפשרת לנו להכריז על הפעולה שיש לבצע בעת יציאה מהפונקציה - בהקשר שקל להבין. ניתן לקרוא ל defer בכל מקום בפונקציה, והפעולה תמיד תרשם לזמן היציאה מהפונקציה. ממש יפה!
4. אנו אומרים למוניטור להמתין לתנאי הסיום שלו.

פלט התוכנית הוא כמובן "!Hello World", והביצועים מצוינים: לא יותר מ 2.000001 השנייה!

בפוסט המשך, אמשיך ואצלול לתוך השפה.

שיהיה בהצלחה!

----

לינקים רלוונטיים

לינק ל Effective Go - מדריך מהיר לשפה מבית גוגל.

לינק ל Go Language Specification - למי שרוצה ״לחפור״.

לינק ל Cheat Sheet מוצלח על התחביר של Go.

למה Go? (כתבה של גוגל) - http://talks.golang.org/2012/splash.article

---

[א] השם "Go" הוא כללי מדי. מזכיר לי ספריית בדיקות ל Delphi שעבדתי איתה, שקראו לה: "Want".
אתם יכולים להבין איזה סיוט זה היה למצוא עליה משהו בגוגל?!

[ב] הפקודה go install my_package לא תתן שום פידבק שמשהו לא תקין קרה. נראה ש Go לא מוצא כזו חבילה - וחבל שהוא לא מתריע.

ניתן להשתמש בפקודה go build -v my_package לבנות את הקוד, כאשר שמות ה packages אמורים להופיע כפלט. אם לא הופיעו - סימן שמשהו בקומפילציה כשל.

Monitoring: מבוא ל Graphite ושימוש ב Time-Series

Graphite היא מערכת Open Source פופולארית למדי לניטור (Monitoring).
בצורה המקוצרת ביותר, היא מבצעת 2 פעולות בסיסיות:

• אוספת מספרים שמשתנים לאורך זמן (להלן "time-series").
• מציגה אותם כגרף.

המערכת מבוססת על עקרונות פשוטים למדי, ומסוגלת לטפל במליוני data points בשנייה.

Graphite זכתה לאימוץ נרחב בתעשייה, ככלי Monitoring חשוב. רבים משתמשים בה (ומספרים על זה): Github, Etsy, אובר, Electronic Arts, ועוד.

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

 מצד שני - צצו גם תלונות שונות על המערכת:

• ניהול הנתונים כקבצים אינו יעיל כאשר מתשאלים הרבה מטריקות (metrics) במקביל. בהמשך נראה שזה מצב כמעט ובלתי נמנע...
• ה UI הוא לא כ"כ יפה...
• יש פונקציונליות חסרה, למשל: aggregation של נתונים, alerts, וגילוי אנומליות...
• ההתקנה של Graphite היא לא פשוטה (הרבה תלויות), והתפעול השוטף שלה - גם עשוי להיות לא כ"כ פשוט.

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


כיום כבר ניתן לראות הרבה תצורות בהן החליפו חלק מהרכיבים של ה "Graphite Stack", ואפילו תצורות ללא אף אחד מהרכיבים המקוריים. Graphite הוא עדיין אחד כלי ה Monitoring הנפוצים ביותר שקיימים.


אם אתם קוראים אדוקים של הבלוג, אתם בוודאי יודעים שאני מאוד אוהב כלי Monitoring בשם New Relic- בעבר כתבתי עליו פוסט.

מה הטעם להשתמש ב Graphite כאשר יש לנו כלי monitoring נהדר כמו New Relic?

1. New Relic הוא כלי יקר [א], וייתכן שיש מערכות שלא משתלם לשלם עבורן את ה premium של New Relic.
2. New Relic מגיש סט מאוד שימושי של מדדים וניתוחים, אבל לעתים אנו רוצים מדדים ש New Relic לא מספק.
1. דוגמה קלאסית: מדדים עסקיים.
   בעולם של Gett: כמה הזמנות יש, כמה נהגים פנויים, כמה נוסעים שממתינים למונית כבר רבע שעה?
2. ב New Relic קיימת פונקציונליות שדומה ל Graphite (עבור מערכות שמנוטרות ברישיון).
   New Relic מקשר את הנתונים בצורה קשיחה לאפליקציה, מה שעלול להקשות. אנחנו במקרה מסוים עזבנו אותו בנקודה זו לטובת Graphite, אם כי לא התאמצנו יותר מדי להשתמש בו. ייתכן ויש לזה פתרון.

Graphana - ה Dashboard ה"חם" בעולם ה Graphite כיום.

הארכיטקטורה של Graphite

בצורה פשטנית משהו, ניתן לתאר את הארכיטקטורה של Graphite בצורה הבאה:

• ניתן לזהות ב Graphite שלושה רכיבי-על מרכזיים: whisper, carbon ו graphite-web.
• המערכת (Application) שולחת נתונים של מטריקות (metrics) שונות ל carbon מעל tcp (פורט ברירת-מחדל: 2003).
• הפורמט בו מועברים הנתונים הוא מאוד פשוט: some metric name : some value : timestamp.
• קרבון שומר את הנתונים בבסיס הנתונים whisper, בסיס נתונים שמבוסס על קבצים ודומה לכלי ישן, יחסית, שנקרא RRD [ב].
• whisper מנהל קובץ נפרד לכל מטריקה, הוא למעשה סוג של Time Series Database (פרטים בהמשך).
• Graphite-web יודע לקבל קריאת GET (בעזרת endpoint בשם render/) כשהפרמטרים על ה URL מתארים query על מטריקה או מספר מטריקות.
• למשל: הפרמטר הבא סוכם את כמות ה logins היומית:

target=summarize(my.metric.logins, "1d")

• Graphite-web מרנדר PNG אותו הוא מגיש לדפדפן.
  הערה: זהו אלמנט של חוסר יעילות: היום קל יותר לקבל נתונים ולרנדר אותם ב javaScript - כך גם העבודה מתפזרת בין ה clients השונים.

Graphite כתובה ב Python, כאשר carbon ממומש ע"ג twisted (שהוא framework ל event-driven I/O) ו graphite-web כתוב ב django - ספריית MVC מפורסמת שדומה באופייה ל Rails.

Time Series Databases (להלן TSDB)

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

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

1. לדחוס את הנתונים בצורה יעילה יותר.
2. איתור מגמות (trends), מחזורים (cyclical fluctuation), ועונתיות (seasonal fluctuation) בנתונים.
3. לנתח חריגות בנתונים (אנומליות).
4. לנסות לחזות את המשך הסדרה.
5. להיות מסוגלים לחשב (בדיוק כזה או אחר) את ההסתברות להתנהגויות עתידיות של הסדרה. למשל: הסבירות לקטסטרופה עתידית.

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

מקור: Sabbir Rehman

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


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

• ניצור טבלה לכל מדד (למשל: צריכת זכרון של שרת A, צריכת זכרון של שרת B, כמות פעולות IO של שרת A,... וכו')
• בכל טבלה יהיו שתי עמודות: זמן, וערך המדד.

כאשר יש לנו *הרבה* נתונים (מה שקורה לעתים קרובות ב Monitoring), ניתן לבצע אחת מ-2 אופטימיזציות מקובלות:

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

דוגמה לדחיסה של נתוני סדרה עתית לרשומה / אובייקט יחיד. מקור: O'Rielly, באדיבות MapR.

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

• Splunk (מוצר proprietary)
• משמש בעיקר לאינדוקס וניתוח נתונים (לא ממש monitoring), יותר נכון להשוות אותו ל ELK Stack מאשר ל Graphite Stack (למרות שהוא נחשב מוצר TSDB).
• InfluxDB (כתוב ב Go, יכול לחבר אותו ל Storage Engines שונים כמו LevelDB או RockDB).
• ניתן לאפיין אותו בפשטות התקנה / תפעול. הוא מתיימר להחליף את כל ה Graphite Stack בעתיד, ובנוסף הוא תומך במודל של time-events, שהוא רחב יותר ממודל ה time-series הקלאסי (מה שבא קצת על חשבון יעילות אכסון וביצועים). אולי שווה להקדיש לו פוסט בעתיד...
• OpenTSDB (הממומש מעל Hadoop HBase)
• ניתן לאפיין אותו ביכולת לטפל בכמויות גדולות מאוד של נתונים, ובמהירות. הוא מהיר בסדר גודל מ InfluxDB - כאשר כמות הנתונים גדולה מאוד.

TSDB כוללים לרוב עוד כמה פונקציות מסביב למודל של סדרות עתיות:

• downsampling - היכולת לשלוף נתונים ביעילות ברזולוציה קטנה יותר מזו שנשמרה (למשל: אנו שומרים מדד כל שניה, אך רוצים לשלוף את הערכים של פעם בחמש דקות).
• ביצוע פעולות השוואה / חישוב בין סדרות עתיות שונות, או מקטעים שונים באותה סדרה עתית. למשל: מה ההבדל בין התנהגות המדד היום, להתנהגותו באותו היום - לפני שבוע?
• אינדוקס הערכים ושליפה מהירה שלהם. למשל: שלוף את כל מקטעי הזמן בחודש האחרון בהם ה CPU utilization היה גבוה מ 70% - בצורה יעילה (ובהנחה שזה אירוע דיי נדיר).

סה"כ TSDBs כוללים tradeoff מאוד ברור: מודל נתונים פשוט ובסיסי של סדרות עתיות, עבורן ה TSDB יעיל בצורה לא-רגילה.

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

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

סיכום

בפוסט זה הכרנו את Graphite, כלי (או אולי Stack) טכנולוגיות פופולארי מאוד, בקוד פתוח - לניטור מערכות. הכח שלו - הוא ביכולת ה customization: ניתן להשתמש בו ל System Monitoring, ל Application Monitoring ואף ל Business Performance Monitoring. הבסיס שלו הוא דיי פשוט ויעיל - מה שתרם לפופולאריות הרבה שלו.

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

בינתיים, אתם יכולים לגשת ל-2 הלינקים העוסקים בארכיטקטורה למטה - הם לא-רעים.


שיהיה בהצלחה!

----

[א] ע"פ מקורות זרים: כ 100$ לחודש לשרת. ע"פ מקורות זרים: ניתן להוריד את המחיר הנ"ל לבערך חצי - אם אתם צרכנים כבדים (יש לכם מאות שרתים מנוטרים). מה המחיר לאלפים? לרוב אם יש לכם יותר מכמה מאות שרתים - אתם לא תשלמו כבר ל NR, אלא תשתמשו ב open source כמו nagios עם הרחבות שלכם...

[ב] RRD הוא קיצור של Round Robin Database - על שם כך ששמר על קבצים בגודל קבוע בדיסק, ועשה שימוש חוזר בשטח שלהם.


----

לינקים רלוונטיים


רשימת כלי 3rd-party שעובדים עם Graphite:
http://graphite.readthedocs.org/en/latest/tools.html


הארכיטקטורה של Graphite, כפי שמתוארת ע"י היוצר שלה, כריס דיוויס:
http://aosabook.org/en/graphite.html
תיאור טוב ממקור אחר:
https://grey-boundary.io/the-architecture-of-clustering-graphite/


דרכים למימוש סדרות עתיות על גבי בסיס נתונים רלציוני:
https://academy.datastax.com/demos/getting-started-time-series-data-modeling
http://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql


ספר מבית O'Reilly על TSDB, ו openTSDB בעיקר. ניתן לקבל בחינם במימון MapR (שמשקיעה ב OpenTSDB):
https://www.mapr.com/time-series-databases-new-ways-store-and-access-data

השוואה של 10 TSDBs:
https://blog.outlyer.com/top10-open-source-time-series-databases


Splunk vs. ELK
https://riskfocus.com/splunk-vs-elk-part-1-cost/ (והמשכים...)

Elastic Search as a Time-Series datastore:
https://www.elastic.co/blog/elasticsearch-as-a-time-series-data-store

7 ההרגלים של אנשי תוכנה אפקטיביים במיוחד (חלק ב)

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

הרגל שלישי: עשה ראשית את הדברים החשובים (AKA איזון בין חשוב ודחוף)

אנשים רבים בתעשיית התוכנה "מכורים לדחוף"  (urgent).

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

נחלק את סוגי המשימות שיש בידנו ל-4 רבעים:

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

כמו כן ישנן שיטות שונות לניהול זמן, שרובן מתנהל בד"כ כך:

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

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


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

ההסבר לכך הוא כזה:

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

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

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

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

תמיד יהיו דברים שלא נעשה.

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

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

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

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

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

עוד כמה המלצות:

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

ההרגל השלישי מתואר בהרחבה בספר של קווי שנקרא First Things First.

הרגל רביעי: חתור לפתרונות Win/Win עם אחרים (AKA החיים הם לא משחק סכום 0)

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

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

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

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

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

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

אמון ניתן לשפר בעזרת:

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

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

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

קווי מתאר מודל של התפתחות אישית לאפקטיביות, ובו 3 שלבים:

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

ההרגל הרביעי (חשוב "מנצח/מנצח") הוא זה שמכניס אותנו לעולם התלות-ההדדית.

קווי כתב ספר ביחיד עם בנו שמוקדש לנושא. הספר נקרא The speed of trust.

הרגל חמישי: קודם הבן, ורק אח"כ - היה מובן (AKA שתי אוזניים, ופה אחד)

כשמישהו מדבר איתנו, אנו נמצאים באחת מ-4 רמות הקשבה:

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

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

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

אלמנט חשוב בהקשבה אמפתית הוא ניסוח מחדש של דברי האחר, על מנת ש:

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

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


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


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

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


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

הרגל שישי: יצירת סינרגיה (AKA מציאת אלטרנטיבה שלישית)

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

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

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

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

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

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

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

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

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

הרגל שביעי: חדד את המסור (AKA למידה מתמשכת)

ההרגל הזה הוא יחסית טריוואלי: תמיד תמשיך להתפתח.

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

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

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

כמה השגות נוספות:

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

אז כיצד הופכים התנהגות - להרגל

הרגל נבנה מתהליך בן כמה שלבים:

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

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

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

לדוגמה ארוחה במסעדת מקדונלדס לילדים:

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

דוגמה נוספת:

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

דוגמה קונקרטית לתחום שלנו:

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

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

כדאי שהטריגר יהיה פשוט וברור.

הפרס יכול להיות חיצוני ("שבחים מאחרים") או פנימי (אתם שבעי-רצון מהתוצאה).

סיכום

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

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

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

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


שיהיה בהצלחה!