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

לדוגמא, עבור שאלה בנוד, צריך להקדים לפני השאילתה nodejs create some action ולכאורה זה עדיף מאשר create some action in nodejs
אם זו פלטפורמה שמתארחת בפלטפורמה ראשית, לדוגמא שאלה ב request בנוד, אכתוב nodejs request ... ולא אסתפק ב request כי זה עלול להביא תוצאות מrequest אחר
אבל אם זה שם שבא לידי שימוש רק תחת הפלטפורמה הראשית, לדוגמא express.js אז זה מיותר להקדים nodejs ויתכן שאפילו גורע, כי גוגל עלול להביא תוצאות ששייכות רק לנוד ולא לאקספרס.

בכל שאלה צריך להבחין האם זו שאלה של תחביר שפה, או שאלה ספציפית לטכנולוגיה, לדוגמא שאלה כמו nodejs create random string אמורה להיות פחות יעילה מאשר JS create random string

בחיפוש עבור שפה GO, המילה GO בעייתית ולא תמיד תהיה ממוקדת כי זו מילה רחבה ששייכת להמון מקומות חוץ מהשפה, צריך לחפש golang כדי למקד את החיפוש.

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

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

להבנתי הקלושה, להערות יש 2 מטרות:

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

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

// calculate distance
// a = begin
// b = end
function dis(a, b){
    return b - a
}

היא עבירה, וההערה שמסבירה מה היא אמורה לעשות לא מתקנת אותה

פונקציה תקינה אמורה להראות כך:

function calculateDistance(begin, end){
    return end - begin
}

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

/**
 * 
 * @param begin {number}
 * @param end {number}
 * @returns {number}
 */
function calculateDistance(begin, end){
    return end - begin
}

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

המשך אולי יבוא. כל המוסיף מוסיפים לו.
הערות יתקבלו בברכה, כולל כל סוגי ההערות

ולקינוח
https://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered

@yits אמר במי עוד משתגע מהתנהגות כרום לגבי טקסט bidi?:

@dovid אמר במי עוד משתגע מהתנהגות כרום לגבי טקסט bidi?:

@yossiz העלית קובץ HTML והוא נפתח בדפדפן, זה חור אבטחה של ממש!
אני רץ לטפל בזה.

ואגב מה החור אבטחה בזה?

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

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

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

מהי אם כן הדרך הנכונה להיעזר?

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

אקווה שעזרתי בהצלחה

@yossiz אמר באפשר לעשות קישור למלל מסויים בדף, הידעתם?:

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

javascript:(function () {
    let text = getSelection().toString().trim();
    let url = window.location.href.replace(/#[^#]+/, '') + `#:~:text=${encodeURIComponent(text)}`;
    let input = document.createElement('input');
    input.value = url;
    document.body.appendChild(input);
    input.select();
    document.execCommand("copy");
    input.remove();
})()

א.
קומפוננטה = רכיב. קבוצת קוד HTML שמקושרת לקוד JS ששולט עליה.
אפשר לעשות בקומפוננטה שימוש חוזר, כמו שבקוד JS אתה כותב כמה שורות בתוך פונקציה אחת, וקורא לפונקציה כמה פעמים, כך אתה עושה קומפוננטה אחת וקורא לה מאיפה שאתה רוצה כמה פעמים שאתה רוצה.
לכל קומפוננטה יש "מחזור חיים" הוי אומר כשאתה קורא לה אתה טוען אותה והיא מתחילה לחיות, כשהיא נעלמת אז היא מתה, יש לה כמה שלבים מהטעינה ועד המיתה.
כדי שתוכל לשלוט על האירועים במחזור החיים, אנגולר מספקת לך מתודות שנקראות בכל אירוע, כלומר כשהיא מתחילה את החיים, אנגולר קוראת למתודה ngOnInit, כשהיא מתה אנגולר קוראת למתודה ngOnDestroy, כשהתצוגה שלה משתנה נקראת המתודה ngAfterViewChecked, וכן על זה הדרך.
זה ההסבר למתודה ngOnInit, שם אתה קובע מה יקרה כשהמתודה תתחיל את מחזור החיים.
השורה implements OnInit זה שורה הצהרתית, אליבא דאמת היא מיותרת והקוד יפעל גם בלעדיה, היא נועדה להסביר לטייפסקריפט שהמחלקה הזו מממשת אינטרפייס שמכיל את המתודה ngOnInit.

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

<app-chlid-component></app-chlid-component>

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

<app-chlid-component [product]="someProduct" ></app-chlid-component>

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

@Input() product

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

@Ouptput() someData = new EventEmitter<any>()

...

this.someData.emit('data')

ובקריאה לילד מוסיפים

<app-chlid-component [product]="someProduct" (someData)="dataHandler"></app-chlid-component>

כאשר ה dataHandler היא מתודה של המחלקה שמטפלת באירוע שנשלח מהילד

וןמי שלא מחזיק חוסם פרסומות יכול להוסיף את הסימניה הזו

javascript:document.querySelector('.YM.YN.Y5').remove()

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

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

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

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

עריכה: דוד קידמני, וברוך שכיוונתי

@chagold יש דרך לשרשר פרמטרים לפי הספר עם המחלקה URLSearchParams

const params = new URLSearchParams();
params.append('parameter1', 1)
params.append('parameter2', 2)


fetch('https://example.com?' + params.toString)

ואפשר גם לבנות את כל ה URL לפי הספר

const url = new URL('https://example.com');
url.search = params.toString();

fetch(url.toString())

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

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

@מנצפך אמר בShared service in angular:

הערה צדדית, חלק מזה מיותר:

export class AppComponent {
  product;
  dataService: DataService; // מיותר
  constructor(dataService: DataService) {
    this.dataService = dataService; // מיותר
    this.product = this.dataService.product;
    this.dataService.product = {
      name: "Computer", id: 1
    }
  }
}

TS עושה את זה לבד, רק תגדיר אם זה פרטי או ציבורי
https://www.typescriptlang.org/play?#code/MYGwhgzhAECCAO8DCB7AtvFA7AplgLgN4CwAUNBdMNhPgE4Cuw+KdAFPAwEYgCWw0ACZh8YAMo46AN344AXNDBYAngEpCAXzIagA

@yossiz אני הבנתי שזו נעילה מנומסת של הדיון

@yossiz אמר בחידה מתמטית לשמחת החג ולחדד את מוחות הילדים (והמבוגרים):

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

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

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

@chagold אמר בחידה מתמטית לשמחת החג ולחדד את מוחות הילדים (והמבוגרים):

אני טועה?

כן, העדיפות היא של 2/3 במקום 1/3
קרא את הניסוח הזה
https://tchumim.com/post/111212

@nigun אמר בחידה מתמטית לשמחת החג ולחדד את מוחות הילדים (והמבוגרים):

ובדיוק על זה אני מתווכח.

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

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

@nigun אמר בחידה מתמטית לשמחת החג ולחדד את מוחות הילדים (והמבוגרים):

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

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

@יוסף-בן-שמעון אמר בחידה מתמטית לשמחת החג ולחדד את מוחות הילדים (והמבוגרים):

המנחה פותח דלת אחרת שאין בה את האוצר

(ההדגשה במקור...)