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

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

האמת שהלינק הזה יותר יעיל לפעמים הבאות
https://www.google.com/search?q=vscode+set+defaul+lang&oq=vscode+set+defaul+lang&aqs=chrome..69i57.8631j0j7&sourceid=chrome&ie=UTF-8

https://stackoverflow.com/questions/35904221/change-vscode-default-language-for-new-files

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

@נ-נח קח משהו זריז ב JS

מידות = {}
מידות.ביצה = 1
מידות.לוג = מידות.ביצה * 6
מידות.קב = מידות.לוג * 4
מידות.סאה = מידות.קב * 6
מידות.איפה = מידות.סאה * 3
מידות.כור = מידות.איפה * 10


// כמה לוגין יש בסאה?
מידות.סאה / מידות.לוג

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

@חוקר שקול כתיבה בצורה כזו

const questions = {
    firstname: {
        type: 'input',
        name: 'firstname',
        message: 'Enter firstname ..',
        nextStep () {
            if(answers.talmid) return this.yeshivaCode;
            else return this.otherStep
        }
    }
}

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

אחרי שאתה מגדיר תיקיה אחת, אתה נכנס לאפשרויות תיקיה > תצוגה, ולוחץ על הלחצן "החל על תיקיות"

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

@זעירא זו הנוסחה

\(*\)

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

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

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
	path := r.URL.Path[1:]
	go myfunc(path)
})
http.ListenAndServe(":4000", nil)

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

var arr []string
...
number := c.Params("number")
arr = append(arr, number)
go myfunc(number)
c.Send(number)

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

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

button.click()

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

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

event = new EventEmitter()

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

event.subscribe(handler)

ופולטים אותו כך

event.emit()

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

@גמליאל אמר בספריית מונגוס:

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

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

אם בסוף תלכו על נוד, לא צריך לדעת SQL אפשר ועדיף להשתמש בזה
https://sequelize.org/v5/
כך מתנהלים מול הדאטבייס בצורה הגיונית עם ישויות ואובייקטים, והכל בJS טהור עם פרומיסים
(תודה ל @zvizvi שהכיר לי את זה)

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

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

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