תחומים - פורום חרדי מקצועי

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

@eido כתב בהבנת solid וclean code:

אז מה הוחלט?

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

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

@A0533057932 אני התייחסתי לעיקרון של פונקציה אחת - מטרה אחת, ובעיקר מתי זה כבר חריגה משמעותית מהכלל.
אני לא עובד בכלל עם העקרונות של clean architecture (שזה ספר ופרדיגמת פיתוח על איך לעשות מערכת, הclean code זה של הספר שלו ברמת הקוד) של הדוד בוב.
זה נכון שהזכרתי את SOLID, בטעות, שכחתי שזה ה"סט" שלו.
הוא מאוד טוב במיתוג ויצירת סלוגנים, ולכן השמות שייכים לו (הרעיון של פונקציה ממוקדת כמובן לא שלו, אולם אין לזה שום שם לפניו...), העקרונות שלו מאומצים ומיושמים במידה רבה בתעשיה, אבל אני בכלל לא "גדלתי על ברכיו". אני לא אוהב בכלל את הקיצוניות שלו, ואני חושב שהכללים שלו הם פאנטיים ומביאים בעיות משלהם.
על הclane architecture שמעתי רק לפני שנתיים בערך, וממש לא התחברתי ועם הזמן גם פיתחתי ביקורת של ממש לעקרונות שלו, מה שכולם אומרים ומסכימים שצריך לקחת אותו במידה ולא עד הקצה.
(מה שכן הכרתי ואימצתי זה הספר code complete שהוא בכלל מביע דעות אלא סך הכל מסכם מה עושה נזק ומה עושה תועלת באופן ודאי מהמציאות, וממנו שאבתי עקרונות קידוד, הרבה מהם היו תמיד בקונצנזוס אלא שצריך לשמוע עליהם פעם כדי לקלוט את הכלל).

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

@eido אל תחשוב שזה קל לי!
ראשית אני לא מתעכב על זה, כלומר גם אני נותן שמות גרועים,
אבל אני מקפיד להחליף אותם (לפעמים חמש פעמים תוך יומיים בשעת הפיתוח).
היום הcopilot בהחלט עוזר לי פה ושם, אבל זה רק עזרה, לא חוסך את הבעיה/האתגר, שסתם ככה הוא בריא מאוד כי הוא גם גורם להגדרה ולמימוש של SOLID.
שנית, השם מאוד מאוד תלוי בהקשר. אם אתה יוצר מחלקה בשביל השמירה לDB או מודול, אתה יכול לנצל את שם המרחב שלהם, למשל dbDirect.insertAd. בגלל שבSQL הוספה זה insert השם insert מתאים יותר לשכבת הSQL, ואילו add או save מתאים למתודה עילית יותר.

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

@eido

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

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

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

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

@eido כתב בתכנון טבלאות לפרוייקט:

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

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

@eido, זה היה פילוסופיה.
הפתרון הראשון הוא מצויין,
רק את הגיבוב תעביר לאפליקציה ושיהיה משהו כמו Argon2.

שאלתי כעת את קלוד, הוא מעיר לי שSHA1 נחשב גרוע במיוחד לזה.
לכן GPT אמר שעדיף לגבב בצד האפלקיציה.
לדברי קלוד, גיבוב באפליקציה עם Argon2 מאפשר קצב ניסוי של 500 לשניה, במחשב עם כרטיס מסך ביתי ממוצע.
אם יהיה 1,000 מפרסמים ו20 אלף מאזינים שזה ריאלי, זה 11 שעות לפי מה שאני מחשב כעת לסריקה כוללת, ממוצע לאיתור חצי מזה שזה 5.6 שעות. כל זה בשביל לדעת מי עשה דיסלייק, בעצם שווה את זה...

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

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

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

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

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

 INSERT INTO Rating (UserPhoneHash, TargetPhone, Value) 
 VALUES (SHA1('0527123456'), '0504123456', 5) AS new
 ON DUPLICATE KEY UPDATE Value = new.Value;

בצורה הזו כל משתמש יוכל לדרג רק פעם אחת כל משתמש אחר, דירוג מחדש מעדכן את הקודם.
העמודה UserPhoneHash צריכה להיות CHAR(40) והמפתח הראשי של הטבלה Rating צריך להיות מבוסס UserPhoneHash+TargetPhone.

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

@eido כתב בתכנון טבלאות לפרוייקט:

מאזין מחייג ומדרג את המספר הנ"ל (יותר נכון את האדם שמאחוריו) מ1 עד 5

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

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