קטגוריה: כללי

כניסה לפרויקט קיים

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

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

התחלה

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

טעויות בכניסה לקוד/פרויקט קיים

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

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

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

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

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

הדרך שלי ללמוד

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

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

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

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

רכיבים קטנים

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

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

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

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

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

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

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

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

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

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

פודקאסטים שאני מקשיב להם

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

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

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

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

פודקאסטים טכניים:

להמשיך לקרוא

האלמות

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

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

2013 במבט לאחור

העוזרים הנאמנים של סטטיסטיקות WordPress.com הכינו דוח שנתי לשנת 2013 עבור בלוג זה.

הנה תקציר:

אולם האופרה בסידני יכול להכיל 2,700 איש. בבלוג הזה ביקרו בערך 28,000 פעמים בשנת 2013. אם הבלוג היה אולם האופרה בסידני, הוא היה מוכר את כל הכרטיסים לבערך 10 הצגות כדי שיצפו בו אותה כמות אנשים.

לחץ כאן כדי לראות את הדוח המלא.

לראות שונה – פוסט ה 1,000

1000-posts

זהו הגלגול השלישי של הבלוג "לראות שונה". והוא הגיע עם פוסט זה, ל1,000 פוסטים אשר מפורסמים כאן בפועל.
את הבלוג התחלתי ב11 לאוגוסט 2007 והוא התחיל עם סיכום אוגוסט פנגווין 2007.
היות והיה היום אוגוסט פנגווין, החלטתי לפרסם קצת מוקדם יותר את פוסט ה1,000 ולאחריו את סיכום אוגוסט פנגווין 2012 🙂

קצת סטטיסטיקה: נכון לזמן כתיבת פוסט זה, ישנם 3,316 תגובות בבלוג. כאשר אינני כותב פוסטים, כמות הצפיות נעה בבלוג בין 30 ל50 ביום, וכאשר אני כותב בלוג, כמות הצפיות נעה בין 90 ל 130 צפיות באותו היום ולפעמים גם ביום לאחריו.
הפוסט עם הכי הרבה תגובות וצפיות לפרק זמן הכי קצר (למעלה מ500 היו ביומיים הראשונים שלו), היה הפוסט הכי מדובר שלי (שהגיע גם לכלכליסט) – לעבוד עם מערכת הפעלה לא מוכרת.

כאשר יש קטגוריה בשם "קוד פתוח", הבלוג מתפרסם גם ב planet.foss.il, וכאשר הוא לא נמצא (ויש פוסטים אשר אינם קשורים לקוד פתוח ותכנה חופשית, או מעניינים בהכרח אנשים טכניים ברשימה), הוא מפורסם רק ב blogs.hamakor.org.il.

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

לקוח גרפי ל xml-rpc

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

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

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

אחד הדברים המדהימים שגיליתי על התוכנה אשר הודרה כמובן באמצעות FPC, היא שלמרות שהתוכנה עברה 4 הפצות לינוקס (אובונטו, מנדריבה, דביאן וארץ') ובתוך ההפצות גם גרסאות שונות של אותה הפצה, ו3 מחשבים שונים (מחשב שולחני, מחשב נישא, ומחשב של לקוח בתוך VirtualBox -> כן גם לקוחות שלי השתמשו בה לבדיקות קוד שלהם), אבל כל עוד ה API של GTK2 (במקרה שלי -> אני מהדר לסביבה הגרפית הזו) לא השתנה, התוכנה עבדה ללא בעיה. רק כאשר ה API של GTK2 השתנה קצת, הייתי צריך להדר את התוכנה מחדש בלי לשנות את הקוד שלי, והכל חזר להיות רגיל.

אז אני עובד עם התוכנה הזו שכתבתי לפני 3.5 שנים (או קצת יותר), ואז התחלתי לכתוב גם תוכנות אשר משתמשות ב REST וב JSON לבקשת הלקוחות, ופתאום התוכנה לצערי כבר לא מתאימה לזה. אז לקחתי את הקוד והתחלתי לעשות לו refactoring וליצור לו תמיכה במספר RPC שונים כדוגמת JSON בנוסף ל XMLRPC, ושליחה של טקסט נקי (text/plain). כרגע נשאר לי להוסיף תמיכה לעבודה עם REST "נקי" (כלומר פרמטרים ועבודה עם GET, POST, DELETE וכו'), והתוכנה שוב תהיה שלמה לצרכים שלי. יותר מזה , הרבה מעבודות ה refactoring היו בשביל להחליף ספריית HTTP. אמנם אני לא מת עליה (על הספרייה החדשה), אבל היא גמישה יותר לצרכים שלי (עד שאלס ישכתב את הספריית HTTP ואולי אחזור לlNet),  ובנוסף הגישה עכשיו של התוכנה גמישה יותר, כך שניתן להוסיף לה תכונות חדשות כאשר הדבר לא ידרוש ממני לשכתב קוד בצורה דרסטית כמו העבודה כאן.

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

את הקוד תוכלו למצוא בכתובת הבאה:

https://github.com/ik5/xmlrpc-client-ui

עידוק

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

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

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

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

2,000 תגובות מאושרות

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

חגיגות ה2,000 התחילו ויסתיימו בתגובה ה3,000 🙂

עידו

עבודה עם xmlrpc ברובי

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

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

הדוגמאות הרגילות מציגות את זה בצורה הבאה:

require 'xmlrpc/client'
server = XMLRPC::Client.new('127.0.0.1', '/', 80)
server.call('test',  'a','b')

אבל בשביל "שם" ו"ערך" אנחנו צריכים להשתמש בזה בצורה הבאה:

require 'xmlrpc/client'
server = XMLRPC::Client.new('127.0.0.1', '/', 80)
server.call('test', { 'a' => 'b'})

אני מקווה שזה יעזור לעוד אנשים.