חשיבת מפתחים לטווח רחוק..
-
@katz אמר בחשיבת מפתחים לטווח רחוק..:
הערך של השנה החדשה עומד על 2,201,010,001
למי שתהה: שני הספרות הראשונות מייצגות את השנה (השאר בפורמט: חודש, יום, שעה ודקה).
Date(year: 22, month: 01, day: 01, hour: 00, minute: 01)
אגב שימוש בUnsigned Int היה מאפשר עשרים שנה נוספות.
-
@katz
אהבתי את הפתרון שלהם
פשוט להשאר בשנת 2021
ולשנות את השם של העדכון ל2112330001
דהיינו ה33 לדצמבר
והם כותביםThe scanning engine will continue to receive updates in this new sequence.
אז מסתבר שימשיכו לעדכן עד 2112990001
ואז יצטרכו לעבור לחודש ה13.....
אא"כ יחליטו לעדכן את המשתנה לUnsigned Int וידחו את הבעיה לעוד 20 שנה.בכל אופן לא נראה שזה נובע מכך שלא חשבו קדימה
אלא פשוט מתכנת שלא ידע מה המגבלות של signed Int. -
@ארכיטקט אמר בחשיבת מפתחים לטווח רחוק..:
חולק עליך, ממש לא טיפה, צריך להשקיע אוקיינוס של זמן לטווח הרחוק, וטיפה כדי שיעבוד עכשיו.
חולק על שניכם, אם אתה לא מפתח מערכת לטילים בליסטיים או לכור הגרעיני, אל תשקיע מחשבה בטווח יותר מידי רחוק, זה רק יסבך את המערכת, כל עוד אתה מפתח אפליקציות שכונתיות נחמדות תשקיע בטווח הקרוב, פעם בכמה שנים תשכתב הכל וזהו, זה יותר זול מלהשקיע לטווח הרחוק, בערך כמו לקנות קומקום במאה שקל פעם בשנה במקום לקנות בשלש מאות שקל פעם בשנתיים
ודיה לחסידה שיצאה בשלום... -
@יוסף-בן-שמעון
בסופו של דבר השאלה היא מה גודל הסיכון ועד כמה אתה יכול להרשות לעצמך ללמוד מהטעויות של עצמך ולא להשקיע זמן בללמוד את הטעויות של אחרים.. -
@nigun אמר בחשיבת מפתחים לטווח רחוק..:
בכל אופן לא נראה שזה נובע מכך שלא חשבו קדימה, אלא פשוט מתכנת שלא ידע מה המגבלות של signed Int
המגבלות הקדימו את גילוי הבעיה, לא יצרו אותה, כך שגם אם האיש היה משתמש עם Unsigned Int, הייתי שולח אותו לדרכו.
אם כי בהתחשב בקצב הפיתוח ותחלופת המוצרים של Microsoft, יתכן שלמתכנתים שם באמת אין סיבה לתכנן יותר מדי... -
@יוסף-בן-שמעון אמר בחשיבת מפתחים לטווח רחוק..:
בערך כמו לקנות קומקום במאה שקל פעם בשנה במקום לקנות בשלש מאות שקל פעם בשנתיים
זאת בדיוק הנקודה, השחתת הנפש על ידי הרגלים מסחריים נוסח ארה"ב/סין. תקנה בזול ותחליף כל שנתיים.
לא לא!!! קומקום חשמלי אמור להחזיק ארבעים שנה, אינני יודע את גילך אבל אני עוד זוכר את המקררים של אמקור שאורך החיים שלהם היה בין 25 ל 30 שנה. וככה צריך לחיות, זה עניין עקרוני ולא קשור לניהול סיכונים.
וכן, אני בן אדם עקרוני שמוכן להרוג ולהיהרג על עקרונות.
ראה "קונספירציית הנורה החשמלית".
כשאני חושב על הדברים האלו תמיד אני חושב על SQL עשרות שנים עברו ולא נס ליחה, כמה הכלכלה תלויה בשפה הזו. והיא כאן כדי להישאר. -
@ארכיטקט אמר בחשיבת מפתחים לטווח רחוק..:
השחתת הנפש על ידי הרגלים מסחריים נוסח ארה"ב/סין. תקנה בזול ותחליף כל שנתיים
נו נו...
בכל מקרה כשכותבים קוד צריך (לדעתי כמובן) לחשוב באופן טכני בלבד, מה הצורה הכי משתלמת ביחס השקעה > תוצאה
כמובן שאם לדוגמה בדרך מסוימת אתה לומד על הדרך עוד משהו, כמו שיטה נוספת וכדומה, זה גם נכנס בצד של ה"תוצאה"
אבל חשבון כזה של הרגלי נפש ומידות וכדומה לא אמורות להיכנס בקוד, אלא אך ורק מה הדרך הכי טובה מבחינת השקעה > תוצאה לכתוב אותו.וכמו ש @יוסף-בן-שמעון אמר בחשיבת מפתחים לטווח רחוק..:
כל עוד אתה מפתח אפליקציות שכונתיות נחמדות תשקיע בטווח הקרוב, פעם בכמה שנים תשכתב הכל וזהו, זה יותר זול מלהשקיע לטווח הרחוק
כיוון שברגע שאתה מפתח מערכת גדולה ומורכבת, מבחינת השקעה > תוצאה טכנית ופשוטה, עדיף לך להשקיע מראש בתכנון, מאשר לקחת סיכון שמשהו ישתבש
ככה אני רואה את הדברים. כמובן שאפשר לחלוק עליי... -
@צדיק-תמים אמר בחשיבת מפתחים לטווח רחוק..:
כמובן שאפשר לחלוק עליי...
טיפ ממני, אם אתה רוצה להזמין אנשים לחלוק עליך, תודיע שאתה לא נותן לא אחד לחלוק עליך, ואסור לחלוק עליך, ואין שום צד אחר. זה מזמין יותר מכל הצהרה אחרת