מגה פוסט – שרת חדש, טיפוסי אישיות ועוד

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

שרת חדש

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

למעשה הייתי מרוצה מספיק מeSecureData (אליהם עברתי מHCOOP לפני פחות משנה וחצי).
מהירות התקשורת היתה קצת מאכזבת אבל לא היו יותר מדי תקלות.
אז למה עברתי?
במסגרת העבודה שלי בface.com (כן, אני עובד בface.com, לא חושב שיצא לי להזכיר את זה פה עד עכשיו) אני עובד מול חברת אכסון בשם CentralHost בסן דייגו, ומחזיק אצלם מספר לא מבוטל של שרתים. בשנה וחצי בשנה חצי שאני עובד שם, הייתי מאוד מרוצה מהם ומרמת התמיכה שלהם – אם כי המחיר שלהם הוא גבוה משמעותית מזה של eSecureData, לפחות למכונות החזקות שאני מחזיק שם במסגרת העבודה.
בכל אופן, יש לי יחסים מצויינים עם בעל החברה, וכששאלתי אם יש לו הצעה אלטרנטיבית שתאפשר לי להעביר את השרת שלי אליו הוא הסכים לתת לי מחשב באותו מחיר שאני מקבל בeSecureData – שזה $79 לחודש, עם יותר זכרון (4 ג'יגה במקום 2 ג'יגה), ושני הרדיסקים של 500 בתצורת רייד 1 (ראי, אם הרדיסק אחד מת לא קורה כלום ופשוט מחליפים אותו) לעומת הרדיסק אחד בלבד בשרת הישן.
העברתי בעזרתו את השרת למכונה החדשה, ולמעט שינויי הגדרות קטנים בשרת הDNS שאני מריץ, ובהגדרות הDNS ברשת הדומיינים שלי הכל פשוט עובד.
אני בטוח שיהיו עוד חבלי לידה, אבל אם אתם קוראים את זה, אתם עובדים מול השרת החדש.
אז כמו תמיד, יש לי מקום לאורחים. מי שחושב לעבור שרת למשהו יותר רציני מאיכסון משותף בגודדי שיצור קשר. (רק לאנשים שמרגישים בנוח עם SSH).

BoneCP

השתמשתי בProxool בתור Connection pool לבסיס הנתונים במשך די הרבה זמן, ועם הזמן גיליתי בעיות – שאומנם די נדירות אבל מספיק חמורות כדי שאני אחפש פתרון.
חשבתי לפתור אותן בעצמי, וגיליתי שהוא לא מתקמפל על JDK מודרני. שלחתי מייל לרשימת התפוצה שלו לגבי העניין, וחודשים עברו בלי שום תגובה ובלי הודעות נוספות.
היה ריח של פרוייקט מת באוויר, וכשנתקלתי בבעיה נוספת (100% CPU בקוד של פרוקסול לעיתים נדירות), החלטתי לחפש Connection pool אחד.
בסוף הגעתי לBoneCP שאומנם מוגדר כבטא, אבל עובד היטב – וחשוב יותר – המפתח שלו עונה לאימיילים ומתקן באגים.

טיפוסי אישיות

מי שלמד פסיכולוגיה (לא אני) מכיר את העניין הזה לעומק כנראה, אבל אני מניח שרוב הקוראים פה לא למדו פסיכולוגיה אני אכנס לעניין:
במהלך שיטוטי באינטרנט בחיפוש אחרי ספרייה לDecoding של תמונות בC או C++ (יש מילה בעברית לDecoding? פענוח? פרישה?) נתקלתי בCxImage, וראיתי בדף האודות של המפתח שהוא טוען שהאישיות שלו היא מסוג INTJ.
אני די בטוח שנתקלתי בסוג הקטלוג הזה למחלקות אישיות בעבר, אבל הפעם הסתקרנתי, אם הוא INTJ אז מה אני? וכמה הדבר הזה בכלל עובד?

התחלתי לחקור, מסתבר שמדובר במבחן פסיכומטרי שמבוסס על העבודה של קארל יאנג מ1920 ופותח על ידי קתרין קוק בריגס וביתה איזבל בריגס מיירס, והמבחן קרוי על שמן: Myers-Briggs Type Indicator או MTBI.
בגדול, הרעיון הוא שהאישיות של בני אדם נקבעת על ידי ארבעה תכונות, כאשר לכל תכונה יש שני צדדים (מוחצן – מופנם, חושב – מרגיש) וכו', ואצל כל אחד תכונה אחת מכל זוג היא יותר דומיננטית מהשניה.

הזוגות הם:

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

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

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

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

בעיית החלוקה

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

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

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

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

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

Facebook Comments

11 תגובות בנושא “מגה פוסט – שרת חדש, טיפוסי אישיות ועוד”

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

  2. כן אני מכיר כמה שיטות לקירובים.

    יש כמה שיטות שאפילו די מהירות, אבל נותנות קירוב לא ממש טוב, אז הכל שאלה של זמן+SPACE וכמה טוב אתה רוצה להגיע

  3. זאת וריאציה לבעיית ה-knapsack,
    אתה מוכן לקבל תשובה מקורבת(או נכונה הסתברותית)?

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

  5. Decoding

    נראה לי שתרגום המילה Decoding לעברית היא "פענוח" או "שחזור".

    הבעיה העיקרית היא שפולת הקידוד עצמה מגדירה מס' מצבים שונים.
    לדוגמה, המסמך יכול להיות מקודד ב-base64, Hex או אחר, וגם בקידוד עברי, iso, utf וכדומה.
    נראה לי שמן הראוי היה לבדל את ההגדרות, להבחין בין קידוד מפת התווים (iso, utf, win ושאר מרעין בישין) להצגה, לבין קידוד התוכן לתבנית "העברה".

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

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

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

סגור לתגובות.