בקשת מידע | בניית תוכנה שלימה עם AI
-
@פרוזי מה גם שאמרתי כבר ואני זוכר שגם אתה עושה את זה
לאפיין עם GPT או כלי אחר
כך שאתה מביא רק את הרעיונות וכל האפיון והביצועים הגוים עושים בשבילך

אגב הזכרת את קודקס יש לי כבר חצי שנה מנוי אצלו אבל רק בחודש האחרון התחלתי לראות את הביצועים שלו באמת
אני חושב לבטל את המנוי אצל קלוד אפילו -
אגב הזכרת את קודקס יש לי כבר חצי שנה מנוי אצלו אבל רק בחודש האחרון התחלתי לראות את הביצועים שלו באמת
אני חושב לבטל את המנוי אצל קלוד אפילובאיזה מודל אתה משתמש?
-
@עניו-כמשה אתה צודק ואני רואה את זה בחוש
בניתי איזה מערכת מורכבת למדי עם קודקס
לקח לי זמן לפתח את השיטה הנכונה לבנייה איתו ועם GPT בצורה משולבת...
וגם אחרי זה עצם הבנייה זה דבר שדורש הרבה משאבים וזמן, מהאפיון ועד הבניה וניפוי הבאגים.
אבל גם כיום כשהמערכת עובדת פרפקט,
עדיין מדי פעם אני מוצא איזה באג וצריך לתקן אותו, ולפעמים זה באגים ממש מטופשים שברור לי שאם הייתי מכיר את הקוד זה לא היה קורה...
אבל תכלס, אם אתה יושב וחורש את המערכת וכל פונקציה בה, אחרי זמן מסויים המערכת באמת מושלמת ללא באגים...
אם היא כתובה בצורה נכונה? איך האבטחה שלה? אם הייתי יכול לעשות אותה יותר מהירה? את זה אין לי איך לדעת, אבל בשבילי התוצאה מספיקה... תכלס מרעיון לביצוע כיום הדרך הרבה יותר קצרהאם היא כתובה בצורה נכונה? איך האבטחה שלה? אם הייתי יכול לעשות אותה יותר מהירה? את זה אין לי איך לדעת, אבל בשבילי התוצאה מספיקה...
זה בדיוק הדיון!
לא הכל מסתכם בעובד ונראה טוב.
שאני מוציא תוכנה ללקוח אני רוצה לדעת שאני סיימתי איתו. אין לו למה לבוא אליי לבאגים וכאלה, פשוט כי אין...
או שנדיר שיהיו.
השאלה כמה הAI עומד בדרישות, בינתיים ההתרשמות שלי היא שלא, אבל אני לא מומחה גדול בAI אז אולי אני לא כותב נכון. -
אם היא כתובה בצורה נכונה? איך האבטחה שלה? אם הייתי יכול לעשות אותה יותר מהירה? את זה אין לי איך לדעת, אבל בשבילי התוצאה מספיקה...
זה בדיוק הדיון!
לא הכל מסתכם בעובד ונראה טוב.
שאני מוציא תוכנה ללקוח אני רוצה לדעת שאני סיימתי איתו. אין לו למה לבוא אליי לבאגים וכאלה, פשוט כי אין...
או שנדיר שיהיו.
השאלה כמה הAI עומד בדרישות, בינתיים ההתרשמות שלי היא שלא, אבל אני לא מומחה גדול בAI אז אולי אני לא כותב נכון. -
@עניו-כמשה לא יודע אם ראוי לצחוק על זה...
-
@עניו-כמשה לא יודע אם ראוי לצחוק על זה...
-
-
-
-
-
אתם צוחקים, אבל לא פעם אחת ברח להם קוד בטעות... @עניו-כמשה צריך לבקש מ@בנימין-מחשבים, הוא אמר שקלוד חושב שהוא הבעלים שלו...
-
@עידו300 כמה סיכויים אתה נותן לזה? ואז יגיע לא מתייאש וימצא לך בעיות ותתקן ואז שוב...
||1. Race Condition (מרוץ בין פעולות): שני משתמשים שולחים הודעות בו־זמנית, והתהליך שומר מידע בסדר שגוי או דורס עדכון של משתמש אחר.
2. Lost Update (עדכון אבוד): שני תהליכים משנים אותה רשומה, והשינוי של התהליך השני מוחק את השינוי הראשון.
3. Transaction ללא אטומיות: שמירת ההודעה מצליחה, אבל שמירת הקשר שלה נכשלת. מתקבלת הודעה ללא שיוך תקין לשיחה.
4. Foreign Key Orphan (רשומה יתומה): נמחקת שיחה, אך נשארות הודעות שמצביעות על שיחה שאינה קיימת.
5. Unique Constraint חסר: שתי בקשות מקבילות יוצרות שני משתמשים או שני אירועים שאמורים להיות ייחודיים.
6. Migration לא הפיכה: עדכון מבנה בסיס הנתונים נכשל באמצע, ולא ניתן לחזור לגרסה הקודמת בלי לאבד מידע.
סנכרון והודעות
7. Idempotency חסרה: בקשת שליחה חוזרת בעקבות ניתוק יוצרת שתי הודעות במקום הודעה אחת.
8. At-least-once Delivery ללא Deduplication: מערכת התורים מוסרת אותה הודעה כמה פעמים, והמערכת מציגה אותה שוב ושוב.
9. Event Ordering: אירועי עדכון מגיעים בסדר שונה מהסדר שבו התרחשו, והמסך מציג מצב ישן כאילו הוא החדש.
10. Race בין שמירה ל־Broadcast: המערכת משדרת הודעה למשתמשים לפני שהשמירה בבסיס הנתונים הושלמה. משתמשים רואים הודעה שאינה קיימת לאחר רענון.
11. Reconnect Gap: משתמש מתנתק ומתחבר מחדש, והודעות שהתקבלו בזמן הניתוק אינן נטענות.
12. Cache Invalidation Failure: הודעה נמחקת או משתנה, אבל מטמון ישן ממשיך להציג את הגרסה הקודמת.
אבטחה והרשאות
13. Broken Object-Level Authorization (BOLA): השרת בודק שהמשתמש מחובר, אך אינו בודק שהוא מורשה לקרוא את השיחה שאליה הוא מבקש לגשת.
14. IDOR (גישה לאובייקט באמצעות מזהה): שינוי מזהה של הודעה או שיחה בבקשה מאפשר גישה למידע של משתמש אחר, משום שההרשאה אינה נבדקת בצד השרת.
15. Race Condition בהרשאות: משתמש מאבד הרשאה לשיחה, אבל בקשה מקבילה שכבר החלה מצליחה לבצע פעולה לאחר ביטול ההרשאה.
16. Mass Assignment: השרת מקבל מהלקוח שדות שלא היה אמור לאפשר לשנות, כגון תפקיד משתמש או הרשאות מנהל.
17. Stored Cross-Site Scripting (XSS): הודעה הכוללת תוכן זדוני נשמרת ומוצגת בדפדפן באופן שמאפשר להריץ קוד לא מורשה.
תשתית והתאוששות מתקלות
18. Split-Brain: שתי מופעים של השירות מקבלים החלטות סותרות בזמן תקלה בתקשורת, והנתונים ביניהם מתפצלים.
19. Retry Storm: תקלה זמנית גורמת לכל הרכיבים לבצע ניסיונות חוזרים ללא הגבלה, מעמיסה את השרת ומאריכה את התקלה.
20. Partial Failure בזמן מחיקת חשבון: החשבון נמחק, אבל הודעות, קבצים, הרשאות או נתונים אישיים נשארים במערכות אחרות.|| -
@עידו300 כמה סיכויים אתה נותן לזה? ואז יגיע לא מתייאש וימצא לך בעיות ותתקן ואז שוב...
||1. Race Condition (מרוץ בין פעולות): שני משתמשים שולחים הודעות בו־זמנית, והתהליך שומר מידע בסדר שגוי או דורס עדכון של משתמש אחר.
2. Lost Update (עדכון אבוד): שני תהליכים משנים אותה רשומה, והשינוי של התהליך השני מוחק את השינוי הראשון.
3. Transaction ללא אטומיות: שמירת ההודעה מצליחה, אבל שמירת הקשר שלה נכשלת. מתקבלת הודעה ללא שיוך תקין לשיחה.
4. Foreign Key Orphan (רשומה יתומה): נמחקת שיחה, אך נשארות הודעות שמצביעות על שיחה שאינה קיימת.
5. Unique Constraint חסר: שתי בקשות מקבילות יוצרות שני משתמשים או שני אירועים שאמורים להיות ייחודיים.
6. Migration לא הפיכה: עדכון מבנה בסיס הנתונים נכשל באמצע, ולא ניתן לחזור לגרסה הקודמת בלי לאבד מידע.
סנכרון והודעות
7. Idempotency חסרה: בקשת שליחה חוזרת בעקבות ניתוק יוצרת שתי הודעות במקום הודעה אחת.
8. At-least-once Delivery ללא Deduplication: מערכת התורים מוסרת אותה הודעה כמה פעמים, והמערכת מציגה אותה שוב ושוב.
9. Event Ordering: אירועי עדכון מגיעים בסדר שונה מהסדר שבו התרחשו, והמסך מציג מצב ישן כאילו הוא החדש.
10. Race בין שמירה ל־Broadcast: המערכת משדרת הודעה למשתמשים לפני שהשמירה בבסיס הנתונים הושלמה. משתמשים רואים הודעה שאינה קיימת לאחר רענון.
11. Reconnect Gap: משתמש מתנתק ומתחבר מחדש, והודעות שהתקבלו בזמן הניתוק אינן נטענות.
12. Cache Invalidation Failure: הודעה נמחקת או משתנה, אבל מטמון ישן ממשיך להציג את הגרסה הקודמת.
אבטחה והרשאות
13. Broken Object-Level Authorization (BOLA): השרת בודק שהמשתמש מחובר, אך אינו בודק שהוא מורשה לקרוא את השיחה שאליה הוא מבקש לגשת.
14. IDOR (גישה לאובייקט באמצעות מזהה): שינוי מזהה של הודעה או שיחה בבקשה מאפשר גישה למידע של משתמש אחר, משום שההרשאה אינה נבדקת בצד השרת.
15. Race Condition בהרשאות: משתמש מאבד הרשאה לשיחה, אבל בקשה מקבילה שכבר החלה מצליחה לבצע פעולה לאחר ביטול ההרשאה.
16. Mass Assignment: השרת מקבל מהלקוח שדות שלא היה אמור לאפשר לשנות, כגון תפקיד משתמש או הרשאות מנהל.
17. Stored Cross-Site Scripting (XSS): הודעה הכוללת תוכן זדוני נשמרת ומוצגת בדפדפן באופן שמאפשר להריץ קוד לא מורשה.
תשתית והתאוששות מתקלות
18. Split-Brain: שתי מופעים של השירות מקבלים החלטות סותרות בזמן תקלה בתקשורת, והנתונים ביניהם מתפצלים.
19. Retry Storm: תקלה זמנית גורמת לכל הרכיבים לבצע ניסיונות חוזרים ללא הגבלה, מעמיסה את השרת ומאריכה את התקלה.
20. Partial Failure בזמן מחיקת חשבון: החשבון נמחק, אבל הודעות, קבצים, הרשאות או נתונים אישיים נשארים במערכות אחרות.|| -
@אוויר וואוו חתיכת סיקור של הבעיות הבאת כאן.
אבל זה חלק מהענין, אם היית/מתכנת אחר כותב את זה ידנית, הייתם שמים לב לזה? הייתם מטפלים בזה? הAI לא? הAI נכשל... אא"כ זה באגים של שטויות אז יכול לקרות. -
שלום! נראה שהשיחה הזו מעניינת אותך, אבל עדיין אין לך חשבון.
נמאס לכם לגלול בין אותם הפוסטים בכל ביקור? כשנרשמים לחשבון, תמיד תחזרו בדיוק למקום שבו הייתם קודם, ותוכלו לבחור לקבל התראות על תגובות חדשות (בין אם במייל, ובין אם בהתראת פוש). תוכלו גם לשמור סימניות ולפרגן ב-upvote לפוסטים כדי להביע הערכה לחברי קהילה אחרים.
בעזרת התרומה שלך, הפוסט הזה יכול להיות אפילו טוב יותר 💗
הרשמה התחברות