@עימוד-עילית
https://chrome.google.com/webstore/detail/abceolommehmfcheephklpllmcocgmol

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

הקדמה לשיעור 6, ארכיטקטורה של טפסי HTML וקצת על נוד.

תקציר וריענון

קודם כל לקלות המצטרפים אנחנו אוחזים בשלב של קובץ בודד בשם app.js שמכיל את הקוד הבא:

const http = require('http');

var list = [];

function handleAllRequest(req, res) {
  res.setHeader('Content-Type', 'text/html');

  if (req.url == '/')
      res.write('Hello To List Page!');
  else if (req.url == '/add-item')
      res.write(`<form method="POST">
                    Enter the item value: <input type="text" name="the-name" >
                    <br>
                    <input type="submit" >
                  </form>`);
  else
      res.write('Opss... Not Found!');

  res.end();
}

var server = http.createServer(handleAllRequest);
server.listen(3000);

בעת הרצה של קובץ זה בF5 בVSCODE, אפשר להיכנס לכתובות הבאות:
http://localhost:3000/ - רואים כיתוב Hello To List Page!
http://localhost:3000/add-item - רואים טופס ובו שדה בודד, עם לחצן שליחת נתונים. משום מה הכיתוב הוא באנגלית, אולי נגיע להסביר למה. בהמשך הכל יהיה עברית טהורה, אל דאגה!
הטופס הוא מסוג POST שהוסבר לעיל: מתודת POST פונה לכתובת (URL) אבל עם "מסוגלות" לשלוח נתונים בגוף הבקשה, קרי לא בURL. משמעות הצורה היא: נפח בקשה גדול, שיש מוסכמה שאופי הבקשה היא ביצוע פעולה (הדפדפן יתריע במקרה של ריענון, וגם לא ישמור את ה"ביקור" בהיסטוריה).
השליחה לא עושה משהו בינתיים.

וכמו תמיד, שוב הקדמת חובה מייגעת של דברים שכבר נאמרו...
כאמור בהודעה האחרונה בטופס HTML יש שני דרכי שליחה POST וגם GET, אבל שניהם עושים כמעט אותו דבר.
הם לוקחים את ערכי הקלט ואת שמותיהם בהתאמה בפורמט הבא:
שם-שדה-ראשון=ערך&שם-שדה-שני=ערך2&שם-אחר=ערך3&גיל=15
ושולחים אותם לשרת (לכתובת שנבחרה בaction ואם לא נבחרה כזו אז לכתובת הנוכחית).
איך שולחים? רק פה ההבדל במתודה. בGET, זה נוסף לנתיב, כלומר הכתובת כולה נראית למשל ככה:
http://site.com/some-path/add-product?name=camera&value=50
כלומר התוכן מצורף לכתובת אחרי סימן שאלה שמפריד בין הכתובת לבין ערכי בקשת הGET בפורמט האמור.
במתודת POST הכתובת נשארת http://site.com/some-path/add-product בלבד ללא כל תוספת, אבל בגוף הבקשה נוכל לראות* את התוכן הזה שם-שדה-ראשון=ערך&שם-אחר=ערך2&גיל=15 בלי סימן שאלה מקדים.

*איך? אפשר למשל בדפדפן בכלי הפיתוח, בלשונית Network בבחירת בקשת POST בכרטסת Headers למטה תחת Form Data או Palyload.

הערה: שני הקטעים הבאים, הם רשות. לא מזיק בכלל לקרוא אותם..., אבל אפשר להתעייף ולעבור לשיעור 6 - טפסי HTML, צד שרת

גוף בקשת הPOST

הוא תיאורטית ארוך...
המונח גוף הבקשה נקרא בשפת המקצוע body, או גם payload.
הוא בעצם כל תוכן הבקשה, החל מאחרי הכותרות שכמה שקובע איפה נגמר הכותרות זה שורה ריקה.
אין הגבלה עקרונית לגודל בקשה (מעשית יש ברוב המקרים וגם מצד הפרקטיקה), ממילא הPOST מסוגל להעביר הרבה מידע לשרת, בשונה ממתודת GET ששם זה הכתובת עצמה שיש לה הגבלות רשמיות כאלו ואחרות.
למה כל זה משנה כעת? כי כשבאים בnode לחפש את הbody של בקשה (כפי שעשינו במקרה של הurl) לא תמצאו אותו במאפיינים של הreq. למה? כי הוא אפילו לא הגיע לשרת. כלומר מייד כשמתחילה להגיע בקשה, הnode מטפל זה (וזה קורה מהר! כשברקע גוף הבקשה ממשיך להיטען). במידה ונדרש גם תוכן הבקשה, יש לבקש מנוד "להודיע" כשזה ייגמר, ואז להיכנס לפעולה.

"אתה יכול לקרוא לי כשגמרת?" callback ואירועים - Events

הבקשה הזאת לבקש מנוד ש"יודיע" כשהבקשה סיימה להתקבל, נקראת (בעולם התכנות) ל"הירשם לאירוע". כשקורה האירוע - במקרה שלנו סיום קבלת הבקשה מהלקוח, כל מי שהיה "רשום" לקבל הודעה מקבל אותה. צורת הרישום כבר מוכרת לנו, השתמשנו בה בhttp.createServer. סיפקנו שמה בסוגריים של פונקציה שיש להפעיל כאשר קורה אירוע של בקשה חדשה.
צורת ההירשמות הזו של http.createServer נקראת callback, משמעות המילה הזו מקפלת בתוכה call back (קריאה בחזרה): "כשתגמור את מה שאני אומר לך עכשיו, חזור וקרא לX". זה בפועל מממש את רעיון האירוע כי אפשר ככה ל"הירשם" לכל אירוע ע"י שמספקים למי (במקרה שלנו מודול הhttp של נוד) שיודע מתי שיקרה משהו (במקרה שלנו בקשה אינטרנט חדשה) שיודיע לנו - יפעיל את הפונקציה שסיפקנו.
הערה: בדרך כלל callback לא בא לממש את רעיון אירוע שרעיונית הוא רב פעמי (כל פעם שקורא בקשה תפעיל את X), אלא את רעיון המשכיות של פקודה (כשאתה גומר את זה תעשה את זה). ברוב שפות התכנות כשיש שתי שורות קוד, השניה תקרה תמיד אחרי שהראשונה תסיים לחלוטין וגם בJavaScript זה ככה, אולם בJavaScript כל פקודה שקשורה לקלט פלט (קבצים רשת ועוד) היא מסתיימת כביכול מיידית, בחינת "שגר ושכח", אבל עם callback - קרי "מה לעשות כשאני באמת אגמור". אם רוצים שהשורה שלאחריה תקרה רק בסיומה הרי שיש להעבירה לcallback ולא לשים אותה סתם שורה אחריה.

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

נוד, וספריות

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

1. למה דברים כ"כ פשוטים צריכים כ"כ הרבה קוד וסיבוך?
2. למי שמגיע ממחוזות דוטנט או PHP , לכשיראה בהמשך שנעבוד עם ספריות תעלה השאלה - איך במדריך "לפי הספר" של א' ב' של סביבה, נכנסים ספריות? הרי זו התחלה על רגל שמאל לכל סביבה שמכבדת את עצמה שכבר במדריך הראשוני, בGet-Started מדברים על פלאגין/הרחבה שמשמעותם שהסביבה "שכחה" יכולת זו או שהיא שולית בצורך הפיתוח.
3. למי שמכיר את נוד הנוסח הוא: למה הוא לא משתמש בexpress או בXYZ וכו'?

התשובה על 1+2 היא: נוד זה ליבה כה רזה, שאי אפשר לפתח בה משהו אמיתי בלי ספריות.
למה עשו כזה דבר? כי זה הדרך המודרנית בסביבות עבודה ובפרט בקוד פתוח, לעשות הפרדה כלל היותר בין רכיבים ולהימנע ממטריה כוללת של all in one שיש בה כמה נזקים. דמיינו שאנחנו חייבים לקנות את העוף לשבת ואת הסלטים מאותה חברה/חנות.
א. אנחנו נתפשר באחד מהם כי אין לנו יכולת להפריד ולקחת את החנות הטובה לכל אחד מהם, ב. וגם החנות תידרש להיות טובה רק באחד מהם, כי הרי השני כבר "מחוייב". ג. אם אחד ממש יפריע לנו נעזוב את החנות למרות שהשני הוא הכי טוב/זול/מתאים לנו דוקא שמה. ד. היכולת של החברה/חנות להיות טובה יותר בשני תחומים נופלת בהרבה מהיכולת להיות הכי טובים/זולים/מתאימים בתחום אחד
שימו לב למילים "מתאים לנו", כי כמו שבאוכל כל אחד מבין שגם ברמה התיאורטית אין הכל "הכי טוב", שהרי יש מי שמתאים לו ככה ויש אחרת, ככה ויותר זה גם בפיתוח. למרות שיש דרישות נורמליות של רוב היישומים בצרכים, זה רחוק מלהיות אמיתי לכל מקרה. כלומר תמיד יש צורך בהתאמות או בהתנהגות שהיא היפך הצורך הרגיל, ממילא גם אם מתכנתי סביבה הם מלאכים, הרי בשביל שהמוצר שלהם יתאים לכולם תמיד הם צריכים לפתח מאה אלטרנטיבות והגדות לכל יכולת.
לכן כל סביבת עבודה חדשה שמפתחים היום (למעט סביבות שבאות לטפל בחלק שולי או נקודתי של מערכת) נזהרת בעניין הזה - א. לתת חופש מלא למפתח להשתמש לצרכים אחרים בדברים אחרים, ב. להתמקד בנושא אחד ולא להתפזר.
אז אם ככה דרך המלך להשתמש טוב בנוד זה לחבר אליה אליה ספריות מובילות של נושא שאני זקוק לו לפי ההתאמה אלי. מכאן אנו עוברים לשאלה 3, למה אני לא משתמש במדריך פה בספריות, הרי זה לא שייך ככה לכתוב אפליקציה.
התשובה על שאלה 3 כבר נאמרה ברמזים כאלה או אחרים בעבר: המדריך פה אינו לנוד, אלא לפיתוח אינטרנט. כל הסיבה שבחרתי בנוד זה כדי לעקוב אחרי הצרכים ב"קיצורים" וספריות. לראות איפה צריך אותם ובעיקר מה הם עושים, שהשימוש בהם לא יהיה "קסם" שגורם לתלות ולערפל גמור בנבכי העניין אלא כלי שמבינים עם מה הוא מתמודד ומה יכולותיו ותו לא.
אנחנו ממש קרובים לשלב שבו נעבור לשימוש בספריות מפורסמות שיקלו את החיים באופן דרמטי.

לפעמים נקבץ אלמנטים לא בשביל להפוך אותם לקבוצה, אלא כדי להחיל עליהם כמות, כמו {}, כוכבית, פלוס, סימן שאלה, או | (המקרה הכי נפוץ זה סימן | שנותן שתי אופציות אבל רק בחלק מהביטוי או סימן שאלה שהופך קבוצת אלמנטים שלמה לאופציונלית). במקרה כזה, ייתכן שזה יפריע לנו בכלל העובדה שזה הופך לקבוצה (למה? לא יודע, אולי בגלל שיש הרבה קבוצות בביטוי שלנו וצריך כבר לאחוז ראש. אם כי הגיוני בכזה מצב לעשות קבוצות שמיות שמייד אסביר). בשביל לקבץ אלמנטים לא על מנת להפכם לקבוצה אלא כדי להכיל עליהם אופרטורי כמות או |, ניתן לכתוב מייד בתחילת הסוגריים ?:, זה נקרא non-capturing-group, הנה דוגמה של קיבוץ (הירוק מורה על קבוצה), והנה אחרי נטרול של הקבוצה.

קבוצות עם שם

(מממ, לא קיים בJS, אתכם הסליחה (גם לא בES8 למיטב ידיעתי, חבל. עריכה: זה מגיע בES2018). אבל נמצא כמדומני בכל הפלטפורמות האחרות).
לעיתים, זה לא נח לעבוד עם קבוצות לפי אינדקס. גם צריך לאחוז ראש את הסדר, גם במקרה שהביטוי מטופל בקוד הוא הופך קשה לתחזוקה כי כל שינוי בביטוי מחייב היערכות בהתייחסות, וגם לפעמים כל הסדר משתנה מתוצאה לאחרת כי אחת הקבוצות נמצאת במקטע אופציונלי. בשביל זה יש אופציה לתת שמות לקבוצות. זה נורא פשוט, בתחילת הסוגריים שמים סימן שאלה ואחריו סוגריים זויתיות שבתוכם שם הקבוצה - "מצוות (סוכה|לולב|שופר)" נכתוב "מצוות (?<מצוה>סוכה|לולב|שופר)" ואח"כ נוכל להתייחס לקבוצה הזאת באופן שמי, למשל בהחלפה במקום $1, נכתוב ${מצוה}. הנה דוגמה.

סימני עגינה ^-$

אם נרצה לחפש מילה שלמה, למשל סוכה ולא בסוכה, ולא מהסוכה, אז נקדים לה רווח. אלא שאז נאבד את המקרה בה היא מופיעה מייד בתחילת הטקסט. נוכל לציין שלפניה יש או תו רווח או את תחילת הטקסט ע"י סימן העגינה של תחילת הטקסט - ^. נכתוב ככה (^| )סוכה. אותו דבר לגבי הסיום, נכול לדרוש שיש אחריו רווח או סוף הטקסט ע"י הסימן $, (^| )סוכה( |$). שכיח בתכנות שרוצים לבדוק את כלל המחרוזת ולא למצוא רק התאמה בתוכה, ואז כותבים משהו כמו ^סוכה$ - משמעות הביטוי היא התאמה לכלל טקסט הבדיקה, שהרי נכללים בו אין ההתחלה והן סיום הטקסט. כמו"כ בשביל לבדוק מתחיל ב ונגמר ב גם כותבים את אחד מתווי העגינה הללו. למשל באינפוט של טלפון בhtml נוכל לדרוש התאמה לרגקס ^05\d-\d{7}$.
נ.ב. יש סימן מיוחד שמסמן סוף\תחילת מילה, והוא \b. הוא בעצם קיצור ל: או רווח או קצה הטקסט (התחלה או סיום) או פסיק וכו'. יש לדבר הזה בעיה קטנה, זה לא עובד בשום שפה חוץ מאנגלית...

פעם הבאה זה על הדגלים - regex flags

Escap - ביטול משמעות תו מיוחד

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

חלופות - OR

אם אנחנו רוצים תו מבין שתיים אנחנו עושים ככה [אב] שזה אומר או א' או ב'. אבל אם אנחנו רוצים לתת שתיאפשרויות לרצף של יותר מתו בודד, למשל לחפש אור או מנורה, נכתוב עמוד כזה | בין האפשרויות, ככה: אור|מנורה. דוגמה מעשית יותר - https?|ftp זה יאתר או ftp או http (ויש s אופציונלית ע"י הסימן שאלה שאחריה).
בשביל לקבץ אפשרויות יש להשתמש בסוגריים, אבל חובה קודם להכיר את המושג הבא, קבוצות.

קבוצות

קבוצות זה קיבוץ אלמנטים בחיפוש שלנו, המשמעות של הקיבוץ הזה היא בשביל התייחסות אל הקבוצה בהמשך ב1)ביטוי החיפוש עצמו, 2) תוצאה 3)ביטוי ההחלפה.
אני אתייחס בעיקר ל3, שזה מה שקורה בהחלפה. אם אנו רוצים להחליף כל רצף מספרי במסמך למוקף סולמיות. אז אנו מחפשים \d+ אך במה מחליפים? אז יש שתי דרכים להתייחס לכלל התוצאה בביטוי ההחלפה. או $0, או \0. אז אנחנו נכתבו במקרה שלנו בהחלפה #$0#, הנה דוגמה.
בינתיים לא היינו צריכים קבוצות (אם כי $0 משמעותו קבוצה אפס, וזה מתייחס תמיד לכלל הטקסט של התוצאה). אך כעת משימה סבוכה יותר, אנחנו צריכים למצוא מספרים מוקפים במרכאות ולעטוף את המספר שבתוכם בסולמיות. כלומר יש לנו "123" והרצוי כעת הוא "#123#" כמובן שהמספר לא תמיד 123... אז אנחנו מחפשים "\d+", ופה בהחלפה אנחנו צריכים מתכון כזה: מרכאות, סולמית, המספר שהיה בין המרכאות, סולמית מרכאות.
פה יעזור לנו קיבוץ. נכתוב ככה: "(\d+)" ונחליף ככה: "#$1#". דוגמה. בזה שעשינו סוגריים מסביב ה\d+ הגדרנו שכל מה שעונה על הקירטריונים המוקפים מתוך התוצאה, יוגדרו כתת קבוצה בתוצאה. וכעת בהחלפה, יכלנו להתייחס לקבוצה הזו ע"י $1.
מה זה ה$1? ובכן דולר בביטוי ההחלפה שמגיע מייד אחריו מספר, משמש כשומר מקום לקבוצה מהתוצאה (שהוגדרה בביטוי החיפוש). בגלל שבביטוי החיפוש יכולים להיות כמה קבוצות, אז המספר מציין את מספר הקבוצה לפי מיקומה (הראשונה 1 וכו'. 0 מתייחס לכלל הביטוי כולו).

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

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

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

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

@ek0583232948 מי שלומד תכנות הוא מבחינתי יותר ממתחיל,
והוא מתכנת מהסוג שהכי כיף להתכתב איתו בפורום.
(כי בשונה מהרבה שואלים, הוא רוצה להצליח בלימוד ולא בתוצאה ספציפית כל שהיא).

@צדיק-תמים שמתי קוד כזה בקונסול:

 document.addEventListener("keydown", console.log);

ולחצתי על הכפתורים האלה, וזה אכן לא "תפס" את האירוע.
פתחתי את MDN בדף שמתאר את כל המקשים, ואיתרתי את שם המקש: MediaTrackNext.

חיפשתי בגוגל: javascript keydwon MediaTrackNext
הגעתי בתוצאה הראשונה של סטאק לתשובה זו https://stackoverflow.com/a/67046309/1271037
שמפנה בתורה לתשובה זו:
https://stackoverflow.com/a/65132225/1271037

ניסיתי את הקוד הזה:

  navigator.mediaSession.metadata = new MediaMetadata({
    title: 'Unforgettable',
    artist: 'Nat King Cole',
    album: 'The Ultimate Collection (Remastered)',
    artwork: [
      { src: 'https://dummyimage.com/96x96',   sizes: '96x96',   type: 'image/png' },
      { src: 'https://dummyimage.com/128x128', sizes: '128x128', type: 'image/png' },
      { src: 'https://dummyimage.com/192x192', sizes: '192x192', type: 'image/png' },
      { src: 'https://dummyimage.com/256x256', sizes: '256x256', type: 'image/png' },
      { src: 'https://dummyimage.com/384x384', sizes: '384x384', type: 'image/png' },
      { src: 'https://dummyimage.com/512x512', sizes: '512x512', type: 'image/png' },
    ]
  });

navigator.mediaSession.setActionHandler('previoustrack', x=> console.log('previoustrack'));
navigator.mediaSession.setActionHandler('nexttrack', x=> console.log('previoustrack'));

ומה? לא עובד לי.
אז למה כתבתי הכל? אולי זה יקדם אותך.

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

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

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

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

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

הפסקתי את פיתוח התוסף הקודם כי היו לי בעיות מול כרום,
והחלטתי לעשות תוסף רזה רק ל"כל-רגע":
https://chromewebstore.google.com/detail/קול-רגע-נקי/cpmlbbglgncekjdjpffbjgeaamjobplg
הוא פחות משוכלל ממה ששכלל @צדיק-תמים את הקיים וגם הוא לא מכסה שום אתר חוץ מכל-רגע, אבל מצד שני הוא מופיע בחנות.

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

יש עוד מעלה במה שהבאתי בקשר לישראל, קח למשל את הידיעה הזאת:
Israel launches strikes against the Gaza Strip, killing nine Palestinians, including three children. Hamas fires rockets against Israeli targets, at least seven of which towards Jerusalem. Al Jazeera

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

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

זה ממש נמאס הנושאים הללו ששואלים על אמינות ודיוק הGPT.
תמיד היה ברור שהפואנטה היא לא אמינות ודיוק, תארו לכם שכל יום נפתח פה נושא מה אי אפשר לפתור באמצעות פטיש ומסמר, בלי סוף דברים!
אני מדביק פה (מהספר gpt for dummies) רשימת מקרי שימוש קלאסיים בGPT, כלומר תחומים שבהם הוא לעיתים קרובות מסייע:
המלץ על צבעים ושילובי צבעים עבור לוגואים, עיצובי אופנה ועיצובי עיצוב פנים.
(אני יכול להוסיף:
חיבור סלוגנים טובים
המצאת שמות לעסק/מוצר)
צור יצירות מקוריות כגון מאמרים, ספרים אלקטרוניים ועותק מודעה.
חזה את התוצאה של תרחיש עסקי.
לפתח אסטרטגיית השקעה המבוססת על היסטוריית שוק המניות והתנאים הכלכליים הנוכחיים.
בצע אבחנה על סמך תוצאות הבדיקה האמיתיות של המטופל.
כתוב קוד מחשב כדי ליצור משחק מחשב חדש מאפס.
מינוף לידים למכירות.
עורר רעיונות למגוון דברים, החל מבדיקות A/B ועד לפודקאסטים, סמינרים מקוונים וסרטים מלאים.
בדוק אם יש שגיאות בקוד המחשב.
סכם את המשפטים בהסכמי תוכנה, חוזים וצורות אחרות לשפת הדיוטות פשוטה.
חשב את תנאי ההסכם לכלל העלויות.
למד מיומנות או קבל הנחיות למשימה מורכבת.
מצא שגיאה בלוגיקה שלהם לפני יישום ההחלטה שלהם בעולם האמיתי.
כתוב ביוגרפיה וקורות חיים.
לפתח אסטרטגיה שיווקית.
לפתח אסטרטגיית מלחמה.
ניהול שירות לקוחות.
בניית מדיניות חברה.
כתוב מערך שיעור.
כתוב תוכנית עסקית.
כתוב נאום.
חפשו טיפולים ותרופות פוטנציאליות באלפי מחקרים קליניים.
לפתח אסטרטגיית קמפיין פוליטי.

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

@שרה-רחל
הבסיס שאיתו כל ספריה מתחברת בסוף, זה פקודות SQL שנשלחות למסד ע"י הספריות של ADO NET
אפשר לעבוד איתם ישירות אבל זה קצת כבד, יותר נח בד"כ להשתמש עם ספריות עיליות שמקלות את העבודה.

ספריות אלו נקראות בד"כ ORM = Object–relational mapping
כי עיקר התפקיד שלהם נחשב המיפוי של התוצאות החוזרות לאובייקטים של תוכנה.
בשפה עם טיפוסיות קשוחה כמו C# ORM מלא מחייב ייצור מראש של מחלקות בהתאם לטבלאות והקשרים שלהם, בד"כ יש כלים אוטומטיים למקרים קלאסיים שאין דרישות מיוחדות.

Entity Framework (הגירסה כיום היא 6 או Core) היא Full ORM, זו ספריה של מקרוסופט מצויינת.
היא גם מייצרת את כל הSQL לשליפה ולעדכון, היא נחשבת ספריה רצינית ומצריכה לימוד מסויים.

אני ממליץ הרבה פעמים על Dapper שזה מיקרו ORM, זה לא עושה כלום מלבד מיפוי התוצאות לאובייקטים או לאובייקט דינמי, עם פוקנציות הרחבה לConnection שמקילים מאוד על העבודה.

להלן קישורים על הדרך הבסיסית שזה ado:

https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-code-examples
הדוגמה הראשונה שם זה Sql

https://www.jetbrains.com/dotnet/guide/tutorials/basics/ado-net/

Dapper

https://www.learndapper.com/
סקירה של הדרך הקודמת מול Dapper בתמציתיות

Entity Framework

https://docs.microsoft.com/en-us/ef/core/

@one1010 מתחשק לי לענות לך "בשולי המסמך למטה הצד שמאל, קוביה קטנה בלתי נראית שבה יש טרפז בצבע צהבהב חום".
זה מזכיר לי בדיחה על רב חובל שהכריז שתיכף מגיעים לקו המשווה, ביקש ממנו אחד הנוסעים לראות את הקו, הגיש לו רב החובל בגיחוך את המשקפת ובעת שהלה צפה מתח חוט מזקנו ממולה. "אני רואה!" התרגש הנוסע "ואפילו אני רואה גמל שמהלך על גבי הקו!".
כעת ברצינות: כל קובץ דיגיטלי (קובץ MP3, מסמך וורד או אקסל, תמונה, PDF וכו') מכיל בפועל רק קוד בשפה בינארית (שפה בה יש שני תוים בלבד) ממנו מורכב מידע שחלקו הוא הוראות מה להציג (אם בכלל) וחלקו האחר הוא מידע לא להצגה, למשל תאריך יצירת הקובץ. החלק של החתימה נמצא בקובץ רק אין משמעות להצגה שלו, כי כל החתימה איננה משהו ויזואלי, אלא כמו מטבע קריפטו שהינו מידע.

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

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

@yits
בהצפנה לוקחים את הקלט (הקובץ וורד למשל) ועושים לו שינויים רבים (להלן הצפנה) בהתאם למפתח שאמור להיות הסיסמה.

הסיסמה לא משמשת ישירות כמפתח

יש שתי סיבות שלא מצפינים ישירות בסיסמת המשתמש:
א. היא נורא קצרה - כדי שיהיה קשה לפענח את התוצאה המוצפנת נדרש שמפתח ההצפנה לא תהיה קצרה, במקרה שלנו למשל משתמשים במפתח בגודל של 32 תווים (keyBits="256").
ב. היא מצומצמת מאוד באקראיות שלה (משתמש מחשב רגיל יכול להקליד אותיות ולא כל צירוף סיביות, כמו"כ הוא בוחר בד"כ רק באותיות השמישות).

הערבול, ומספר הערבולים

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

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

פעולת הניחוש

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

Rainbow

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

מלח...

בשביל זה צריך שהערבול יהיה ספציפי כמה שיותר לכל מקרה, במילים אחרות שכל מקרה יצטרך טבלה משלו ואז החזרנו את התוקף המנחש לקושי המקורי (כי להכין את הטבלה פעם ראשונה זה לוקח זמן באותה מידה כמו לנחש ישירות).
לכן, לפני כל הערבולים, התוכנה המצפינה מוסיפה "מלח" (salt) לסיסמה. אם הסיסמה היא Abc123 התוכנה מוסיפה לזה טקסט, ורק אז מערבלת. ה"מלח" הזה לא סודי, כי אחרת לא יכולו גם לפתוח את ההצפנה בהינתן הסיסמה, התוקף יודע את הטקסט אבל זה מונע ממנו להשתמש בטבלה מוכנה שהתאימה לסיסמאות ללא מלח או עם מלח אחר.
גם אם התוכנה תוסיף קבוע את אותו טקסט לסיסמה, עדיין זה יגביל את הפורץ מאוד כי הוא יצטרך טבלאות ספציפיות לתוכנה הספצפית. אולם במקרה של אופיס המלח הוא אקראי, כך ששום טבלה מוכנת לא תעזור. במקרה שלנו המלח הוא saltValue="MJXPjFaEW7owXFz2jgRHZg==".

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