ארכיון רשומות מאת: ik_5

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

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

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

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

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

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

להמשיך לקרוא

פיתון למתכנת רובי

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

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

אז מה לא אינטואיטיבי עבורי?  הכל 🙂
סתם, הנה הדגמה קטנה לרובי:

להמשיך לקרוא

vim, neovim ו javascript

אני נחשב למתכנת מסוג full stack מסתבר, ככה לפחות הגדירו אותי אחרים.
אני מוצא את עצמי נמצא רוב הזמן כאשר אני מתכנת לפחות, משתמש בvim, כל עוד לפחות, לא מדובר בשפת Javascript, על שלל ספריותיה, כדוגמת React או Vue אשר איתן אני עובד לרוב.

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

כאשר אני מתכנת בשפות כדוגמת Golang, רובי או פיתון, יש לי כלים ממש איכותיים לנושא עבור vim, גם כאשר אני נוגע למשל בתסריטי teraform, אני עדיין מקבל תמיכה יחסית טובה, אבל כאשר מדובר ב JS, זו כבר בעיה. אני חושב שהסיבות הן שיש הרבה תקנים שהם עדיין במצב של offer ו draft וככה es6 וכיוב', יוצרים אתגרים מעניינים.

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

לאחרונה אפילו עברתי ל neovim, אשר דווקא עושה עבודה מדהימה, עם כמה בעיות ממש קטנות, הוא מספק לי כלי מעט טוב יותר מvim עצמו, הוא אפילו מכיל כמה כלים שלפעמים נדמה ש tmux קצת מיותר (למרות שאני עדיין לא משתמש בו), למשל היכולת לקבל מסוף מובנה עם ‎:terminal אשר עדיין מקבל תוכנות של vim בתוכו.

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

 

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

חשיבה ביקורתית

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

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

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

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

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

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

 

אז מה הקשר של כל זה לטכנולוגיה?

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

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

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

 

מוגש כחומר למחשבה.

ניתוח מחרוזות חלק א' התאוריה (על רגל אחת)

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

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

מתכנת IT

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

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

עכשיו אשאל אתכם שאלה: האם איש DBA שייך לקבוצה הזו? התשובה היא כן. האם הוא איש DevOps? התשובה היא לא.

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

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

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

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

להמשיך לקרוא

הבנת תבניות זמן בשפת Go

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

כאשר מדובר בשפת Go (או Golang למחפשים), הגישה בנויה מעט שונה. במקום place holder רגיל שבו "m" מייצג חודש בעל תו בודד (כלומר אם החודש הוא "5", אז הוא יופיע כ"5", אך אם החודש הוא "10", הוא יופיע כ"10") או "mm" שהוא חודש דו ספרתי (כלומר אם החודש הוא "5", אז הוא יופיע כ "05", וכאשר מדובר בחודש שהמספר שלו הוא "10", הוא עדיין יופיע כ"10") אינה מתקיימת.

התבניות האלו מוחלפות בגישה אחרת, שאותי לפחות מאוד בלבלה במשך הרבה מאוד זמן. הגישה אומרת כי יש לנו offset holders. מה הכוונה? ובכן תאריך ושעה בGo נשמרים בברירת המחדל כמספר שלם בגודל 64 ביט (כלומר int64). בנוסף, ישנו מספר בגודל 32 ביט (int32) שמחזיק בנונו השניות לשנייה מסוימת., ובנוסף לזה, יש גם מערכת לשמור מיקום.
כל המשתנים האלו מאוגדים ברשומה בשם Time.

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

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

בשביל המבנה, יצרו בגו סוג של Fixed Date שהוא המייצג את הימדע הזה:

Mon Jan 2 15:04:05 MST 2006

המידע הזה הוא נקודה קבועה היודעת להיות מתורגמת ל Unix Epoch 1136239445.
להמשיך לקרוא

יצירה וטעינה של ספרייה משותפת בגו

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

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

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

מימוש RDP טבעי בשפת רובי

על רגל אחת, RDP הם ראשי תיבות של Remote Desktop Protocol. אך השם מעט מטעה. זוהי למעשה אסופה של הרבה מאוד פרוטוקולים, חלקם אפילו לא של מיקרוסופט, אלא של ארגון ITU. למעשה הוא מבוסס על סדרה של פרוטוקולים שהחלו את דרכם בארגון ה ITU אשר נועדו לאפשר לתוכנות לשתף מידע ותכנים בניהם.

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

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

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

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

כתובת הפרויקט: https://github.com/Safe-T/rdp-rb

סיכום שנה – 2015

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

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

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

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

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

פרויקט של גוף ממשלתי שהשורשים שלו נטעו בסוף 2012, הגיע למצב של פיילוט ב2015, שעכשיו ב2016 כנראה שיכנס להיות בכל הארץ אצל אותו גוף ממשלתי.

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

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

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

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

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