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

המסך לא משפיע על התכנות אלא על העיניים שלך.
יש הבדל בין הפאנלים של המסכים (VA או IPS). הIPS קצת יותר יקר והוא יותר איכותי, אם כי למשחקים לפעמים מעדיפים דוקא VA.
יש הבדלים של רזולוציה: full-hd, 2K, 4K.
יש מסכים שיודעים להסתובב (PIVOT) ועוד כל מיני פרמטרים שמשפיעים על המחיר.
אבל נשמע שאתה לא צריך את כל הדברים האלה, ואם ככה בהחלט הייתי לוקח את המסך הזול.
אם אתה יושב הרבה שעות מול המסך - הייתי לוקח גודל של 27 אינץ.

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

@קומפיונט לא היה לי זמן לבדוק את זה לעומק,
אבל זה ממש מזכיר לי את הפרוייקט של מיקרוסופט עצמם Maui - וגם הוא אופן סורס בגיטהב - https://github.com/dotnet/maui.
מה יותר טוב באבלוניה?

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

@odeddvir זה לא הבעיה, למרות שמה שהצעת אכן יפתור אותה.
הבעיה שהחבילה create-react-app לא מותקנת לה במחשב גלובלית, או לא מותקנת בכלל, ולכן הnpm לא מכיר אותה.
Npx זה דרך חדשה שנוספה בגרסאות אחרונות יותר של node שמאפשרת להשתמש בחבילה בלי להתקין אותה מקומית, ולכן התשובה שלך תעבוד והיא הדרך המומלצת.
לחילופין, אפשר להריץ את הפקודה
Npm i -g create-react-app
ואז זה יתקין את החבילה גלובלית, דבר שיאפשר להשתמש בה אחר כך מכל נתיב במחשב, אם כי זה פחות מומלץ, כדי להשתמש תמיד בגרסה האחרונה והעדכנית ביותר.

ראה כאן https://create-react-app.dev/docs/getting-started/

@אבי-203 לא הבנתי.
JS מריץ את הפונקציות לפי הסדר שכתבת, אא"כ כתבת לא נכון..
אין סיבה שהפונקציה של הget תרוץ לפני הפונקציות שכתבת לפניה.

תשתף את הקוד..

לפני השימוש ב async / await היו משתמשים בpromise עם then (עדיין אפשר להשתמש בזה, אבל זה לא הולך ביחד..
כשרוצים להשתמש ב then צריך לכתוב ככה:

wixData.get("tormim", truma._id)
  .then(item => {
      item.ishur=  true
      item.status = "מאושר"
      item.card1=  ms

      return wixData.update("tormim", item)
  })
  .then(res => {
      console.log(res)
  })
  .catch(err => console.log(err))

מקווה שזה קצת יעשה לך סדר בדברים האלה

@אבי-203 השימוש בasync / await בא במקום השימוש בפונקציה then().

לכן את הקוד שלך אתה צריך לכתוב כך:

await wixData.get("tormim", truma._id);
// עכשיו הוא לא יריץ את הקוד הבא, עד שהפונקציה get תסיים
// כיון שאתה לא שומר את הערך שחוזר במשתנה, אתה צריך לכתוב ככה:
 const item= await wixData.get("tormim", truma._id);
// עכשיו המשתנה item 
// יכיל את מה שרצית.

item.ishur=  true
item.status = "מאושר"
item.card1=  ms
// גם בשורה הבאה אתה צריך להוסיף לו await
 await wixData.update("tormim", item)

@ש-ב-ח כמה הערות:
א.
Js לא טמבל, ובכוונה הוא א-סינכרוני, כדי שהדפדפן לא יקפא כשהוא מחכה לתגובות מהשרת או מבצע פעולות לדיסק וכדו'.

לשאלתך, פונקציה שמחזירה פרומיס, דהיינו שהיא א-סינכרונית, אפשר לכתוב בחתימה שלה async, ואז לקרוא לה עם await, כלומר תחכה עד שתחזור התשובה.
(מאחורי הקלעים js ממיר את זה לpromise, ומאחורי זה בעצם הופך לcallback..
כי זה בעצם רק צורת כתיבה שהיא יותר קריאה)

@dovid אמר בסליקה ישירות מהאתר:

@avr416 אמר בסליקה ישירות מהאתר:

אחרת אתה עובר על החוק

יש לך מקור? עד כמה שידוע לי אתה אחראי, וחשוף לתביעות של נזק אבל לא עובר על החוק.

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

כך כתוב באתר של ישראכרט:

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

ובהמשך:

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

וראה גם באתר הרשמי שהוקם לכך:
תחת שאלות נפוצות:

מה יקרה אם לא אעמוד בתקן?

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

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

@ש-ב-ח אמר בסליקה ישירות מהאתר:

@חוקר
אין לי עדיין ספק
אני רוצה להעביר את פרטי הכרטיס והעסקה דרך טופס שלי דווקא
בלי אייפרמים ובלי וכו'

איזה אבטחה צריך?
ומי נותן API לכזה דבר?

צריך לעשות הסמכת Pci, זה עולה כמה עשרות אלפי שקלים למיטב ידיעתי..
אחרת אתה עובר על החוק וחשוף לתביעות.
אל תעשה את זה!
תשתמש בredirect או iframe.
בפלאקרד נותנים לך להוסיף קובץ css משלך, ובו אתה יכול לעשות ככל העולה על רוחך, אם רק תלמד קצת css.
אפשר להשתמש ב after או before כדי להסתיר את הכפתור שלהם ולכתוב תוכן אחר ועוד הרבה רעיונות.

אז כמו שכתוב בכותרת C# גרסה 9 שוחררה באופן רשמי לפני כשבועיים.
זה חלק ממהלך יותר רחב של .net 5 שבעצם מאחד את 2 האפשרויות שהיו עד היום (core, framework) לבסיס אחד.
יש בה כמה חידושים מעניינים, נראה לי שאחד הרציניים והגדולים שבהם הוא ההכרזה על Record.

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

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

public record Person(string FirstName, string LastName);

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

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

public class Person
{
    public string? FirstName { get; init; }
    public string? LastName { get; init; }
}

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

var person = new Person { FirstName = "Mads", LastName = "Nielsen" };

אולם לאחר מכן, כל ניסיון לגשת אליהם ולשנות להם את הערך נידון לכשלון!
הדבר הזה הוא נדרש הרבה פעמים כשמתשמשים בpattern של dto (data transfer object) כמו בגישה לדטהבייסים וכדו'.

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

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

var person = new Person { FirstName = "Mads", LastName = "Nielsen" };
var otherPerson = person with { LastName = "Torgersen" };

זה ישכפל לנו את כל המאפיינים שיש באובייקט person חוץ ממה ששינינו עכשיו.

Equal
יתרון נוסף שאנו מקבלים בשימוש בrecord, הוא שמאחורי הקלעים יש לנו דריסה של הפונקציה Equal שלא הייתה שמישה באובייקטים, מכיוון שהיא משווה את הרפרפנס שלהם, ותמיד הם יהיו שונים מכיון שכל אובייקט מצביע למיקום אחר.וממילא לא יכלנו להשתמש בה כדי לבדוק האם האובייקטים מכילים את אותם ערכים למרות שהם שונים. עכשיו כשאנו משתמשים ברקורד, אנו יכולים להשתמש בפונקציה equal ואע"פ שהמצביעים הם שונים, אם הערכים שווים - התשובה תהיה חיובית. (מאחורי הקלעים יש כאן ovveride לפונקציה המקורית שיש לכל אובייקט בC#).

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

var (f, l) = person; 

ונקבל במשתנה f את הערך שנמצא בfirstname וכן בl את הערך השני.
מה שנקרא deconstructor.

כל מה שכתבתי כאן מבוסס על הפוסט שהפניתי אליו, ואני ממש ממליץ לקרוא אותו למי שרוצה. כי נוספו שם עוד הרבה דברים מעניינים, ובקצרה רק אוסיף עוד 2 דברים מעניינים, שלא קשורים לrecord אבל נוספו לתמיכה של השפה:

not operator
נוסף גם האופרטור not שמאפשר לנו לכתוב ככה:

if(x is not null)

Target-typed new expressions
מה זה אומר? שאפשר לחסוך בהצהרה של שם המאפיין.
עד היום יכלנו לכתוב

var x = new Person();

ולא היינו צריכים לכתוב פעמיים person, עכשיו אפשר לכתוב באותה מידה:

Person x = new ();

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

var members = new List<Person>(){new Person("avi","cohen")}
;

וכן על זה הדרך.
היום מספיק לכתוב רק ככה:

var members = new List<Person>(){new ("avi","cohen"),new ("avi","cohen"),new ("avi","cohen")}
;

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

@נתנאל יפה!

אבל אין צורך, ואצאפ כבר עשו לך קיצור לזה..
פשוט כותבים wa.me/972
ואז את המספר טלפון בלי ה0 הראשון.
וזה אוטומטית פותח את ואצאפ במספר הזה.

@מנצפך אמר בjson web token vs cookie auth:

2. ב JWT יש פחות התאמה לשמירת נתונים על הסשן הספציפי. (נניח רוצים לשמור רשימת קניות או כל state אחר.

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

את הסטייט תנהל בקליינט.

איזה קטע!!
אני כבר לפחות שנתיים משתמש רק עם jwt.
זה לא איזה משהו חדש.. וזה אכן נראה שזה הסטנדרט היום בכל הפרוייקטים שממשים api.
באנגולר אני רואה את זה כמעט בכל פרוייקט שאני ניגש אליו.
הייתרון של זה שזה אכן מאפשר לך גישה לapi מכל קליינט שהוא (דפדפן, אפליקציה וכו').
וכן לנהל את המשתמשים מסרביס אחד, ולפנות על ידי הטוקן לביצוע פעולות בסרביסים אחרים כמו שכתבו כאן לפני, דבר שנהיה נפוץ יותר ויותר.
למשל https://auth0.com/ מספק לך אפשרות לנהל את כל המשתמשים שלך באפליקציות שונות, במקום מרכזי אחד. (וכמדומני שהם גם היוצרים של jwt..).
ראה כאן עוד הרחבה
https://auth0.com/docs/tokens/json-web-tokens
https://auth0.com/learn/json-web-tokens/

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

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

לעניות דעתי, זו שאלה בסטטיסטיקה ולא במתמטיקה.
מתמטיקה זה מדע מוחלט, 1+1=2.
כאן אין תשובה נכונה ולא נכונה, כי גם אם ההסתברות שהדלת שהוא בחר זה 1/3 נכון, ולכן עדיף לו לשנות את הבחירה כדי שיהיה לו 2/3, עדיין יכול להיות שהשליש היה נכון ועכשיו הוא יפסיד ולו אין הזדמנויות נוספות..
לכן, אין כאן אמת מוחלטת, יש סיכויי הצלחה יותר גבוהים.
לדעתי זה בתחום מדעי ההסתברות, לא מתמטיקה טהורה.

@yossiz אמר בC# או NODE.JS:

@avr416 אמר בC# או NODE.JS:

נראה לי שלטייפים סטטיים אין קשר להשפעה על הביצועים בכלל

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

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

ראה פייתון.

@yossiz אמר בC# או NODE.JS:

@avr416 אמר בC# או NODE.JS:

אבל דווקא בדברים שצריך בהם הרבה גישה לקבצים וכדו' (I/O) מקובל לומר שזה לא הצד החזק שלו..

נראה לי שזה בדיוק הפוך. המודל של נוד לא טוב לקוד שצורך הרבה CPU כי הכל רץ בתוך thread אחד וה-multi-tasking הוא cooperative ולא preemtive. אבל בקוד עם הרבה I/O זה יותר חסכוני להשתמש ב-thread אחד ו-event loop במקום ב-thread pool. שלא לדבר על PHP בלי thread pool ושום דבר אלא thread (או תהליך) חדש לכל בקשה, זה הכי גרוע כי ה-I/O תוקע את ה-thread עד שהיא תסתיים.

צודק. טעיתי.

@yossiz אמר בC# או NODE.JS:

אני לא מרגיש כך. בשימוש ב-express אני מקבל את הבקשה בצורה מסודרת מאוד. אני לא מכיר איך בדיוק הבקשה נראית בנוד native. אבל אין סיבה לא להשתמש בספריות.

נכון אבל בASP.NET אתה בכלל יכול לא לדעת שיש דבר כזה שנקרא request..
וזה מה שדוד התכוון לברזלים.

@dovid אמר בC# או NODE.JS:

אם אתה מתכוון לכמות התחביר הרבה של C#, כלומר טיפוסים מחלקות ובכלל כל הטיפוסיות הקשוחה,

כן, לזה התכוונתי. אבל זה לא over engineered אלא שפה שונה.
זו שפה עם טייפים סטטיים (שהוא הרבה יותר טוב לביצועים). ו-object oriented. זה מסביר כל ה-over engineering, לא?

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