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

@ארכיטקט אמר בהתקנתי Visual Studio 2022 כאן המקום למי שיודע דברים חשובים על IDE בכלל - דברים ששינו לי את החיים:

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

מסתבר שזה הציק גם למהנדסי מייקרוסופט והיטיבו להוסיף אופציה של global using ב C# 10

global using <fully-qualified-namespace>;

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/using-directive

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

אם תרצה תשובה עם קוד יש באינטרנט פידלים רבים ל MYSQL הנה אחד לדוגמא: https://www.db-fiddle.com/
אם תואיל בטובך ליצור לנו שם טיפלה טבלאות כדי שיהיה כיף לעבוד ולראות את התוצאה אשמח לעזור לך גם עם קוד.
כמו"כ אם אין לך כוח לפידלים אני תמיד עוזר בחינם לאנשים בתנאי שהם לא רשעים (ואני רשאי לקבוע מי רשע ומי לא) אז פנה אלי בפרטי.

@zvizvi אמר בבשורה מרעישה לכל מי שסובל מבעיות UX הנובעות מבלבול בין לחיצות כפולות לבודדות:

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

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

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

מי אני שאתווכח עם הפרופסור

@איש-אחד

גם איך למצוא פתרונות צריך ללמוד...

מושגי יסוד זה החסם העיקרי בין האדם ובין גוגל, כשיש לכימאי בעיה בכימיה ייתכן שגוגל יעזור לו, אבל לא לי, כי אני לא יודע מה לחפש. זכור! גוגל הוא לא מורה! הוא מנוע המספסר בין היודע למחפש. בכדי לקבל מושגי יסוד עליך להשיג מורה בשר ודם, במקרה של תיכנות, גוי זה גם טוב.
החיפוש הבא: asterisk mysql encoding
בתוצאה השניה: https://reviewboard.asterisk.org/r/964/diff/3/
מציג את הפתרון של קודנט.
אבל מי ילמד אותך לחפש את הביטוי הזה שבסך הכל מרכיב 3 מושגי יסוד למשפט אחד (אגב טיפ ממני גוגל עובד טוב יותר בחיפוש בן 3 מילים, ובעיקר אם הם מתמצתים את המושגים שאתה רוצה להרכיב במשפט, כל מילה נוספת עשויה להפחית את איכות החיפוש)

פורסם במקור בפורום CODE613 ב06/11/2017 15:46 (+02:00)

שלום לכולם
הפעם ניכנס ישירות לדבר האקטואלי הבא. כפי שראינו בפרק הקודם "סיבוכיות הרשת" היא איום של ממש על יציבות העולם, מכל הבחינות, הן תחזוקתה ושבריריותה (וכפי שאבי היקר הביא דוגמא פנטסטית, ממש מהשבועות האחרונים) והן מבחינת בעיות האבטחה ההולכות ונעשות קריטיות וסבוכות יותר ויותר. הבעיה המרכזית כפי שזה נראה היא בעיית התלויות הגבוהה, אילו המערכות היו בדידות, הן לא היו פגיעות כל כך. עתיד האינטרנט, כבר אמרנו, הוא לא ימשיך בתצורתו הנוכחית נקודה (כך קיבלתי במסורת).
הפעם נעבור לדבר על התקוות שהאנושות תולה בבינה המלאכותית, שפתחה פתח למאות ענפים שהיו עד כה רחוקים מהמחשב. ובכן אם רשת האינטרנט היא בבחינת קורי עכביש אימתניים שנפרשו על האנושות כולה, הרי שהבינה המלאכותית היא ביצה טובענית ודביקה שאין ממנה שום אמצעי מילוט (אם אכן חלילה יתממשו החזונות של החברות העוסקות בתחום). בכדי להסביר זאת, אכתוב הקדמה קטנה.
תפקוד החברה האנושית כחברה מחייב יסוד אחד בסיסי שבלעדיו אין לה כל קיום: אמון. האמון, כפי שנראה מתקיים בצורה רשתית (כלומר רשת של אמון שבו הקצוות מאמינים זה לזה דרך אמון במישהו אמצעי וחוזר חלילה). ניקח דוגמא פשוטה, יש לנו רופא משפחה, נניח שאנו מכירים אותו אישית משכבר הימים. כשהוא ימליץ לנו על טיפול, לא נחשוד בו שהוא מתכוון לרעתנו. לצורך הטיפול הוא יפנה אותנו לפלוני אלמוני שהוא מספר אחד בתחום, רופא המשפחה סומך על מקצועיותו של אותו אחד, ואנו נלך אחרי ההמלצה הזו, למרות שמעולם לא הכרנו את אותו רופא צד ג'.
יוצא שבעצם האנושות כולה יצרה רשת אדירת מימדים של אמון, שמגיע עד למוסדות הממשל ואף ליחסים בינלאומיים. כל דבר שאנו עושים אם אין לנו בו ידע מספיק, מבוסס על אמון בגורמים שניים ושלישיים, בין אם נרצה ובין אם לאו, אחרת אדם אמור להתחבא במערה ולהמתין למוות ברעב. זאת הסיבה שהשחיתות היא דבר שכל כך מפחיד את הבריות, לא בגלל השקל וחצי שאותו מושחת "החסיר" מהכלכלה, אלא בגלל הפגיעה במנגנון האמון, שהוא כל כך הכרחי לקיום המערכת.
לא נאריך בנושא מרתק זה, על אף שהוא שווה התייחסות ארוכה בפני עצמה. מה שבעיקר נוגע אלינו, הוא שאתה יכול להאמין למישהו, אך ורק מתוך ההנחה שאתה והוא חושבים באופן דומה, הן מבחינת מערכות האינטרסים, והן מבחינת תפיסת המציאות. כשאתה עולה על מטוס, אתה מניח שכל השותפים בתכנונו ובהרכבתו, איש איש בחלקו בדק ויודע איך אותו חלק עובד. ברגע שישנו בן אנוש אחד שיודע איך החלק צריך להיות ואתה סומך עליו, זה מספיק לך. הופה, הגענו לנקודה. נחזור עליה ברגע שישנו בן אנוש אחד שיודע איך החלק צריך להיות ואתה סומך עליו, זה מספיק לך, זאת הסיבה היחידה שאנשים שמים את חייהם יום יום על הכף של ההנדסה הכבדה, עולים על אוטובוסים, שפועלים על מנוע בעירה, ונוסעים על גשרים, שבנויים על יסודות בטון שנבדק על ידי... כימאי אלמוני שאיש לא יודע את שמו מלבד החברה המעסיקה אותו.
אוקיי, נעזוב לרגע את הנושא הזה, ונעבור לתחום הבינה המלאכותית, ישנם כמה סוגים של בינה מלאכותית, האתגר המשותף לכולם, עשיית פעולות שאינן מתמטיות אלא סטטיסטיות, והתמודדות עם כמות נתונים ומשתנים שאין אפשרות לחשב בתוכנה מסורתית. הסוג הפופולרי והנפוץ לבינה מלאכותית, נקרא "רשת נוירונים" או "למידה עמוקה" הסבר נרחב כאן. הבעיה הגדולה ביותר עם בינה מלאכותית, היא שאין מישהו שיודע איך היא צריכה לעבוד, כלומר, לא מדובר במכונה גדולה ומורכבת, שלפחות לכל חלק יש מהנדס שמכיר אותו על בוריו. מדובר על מכונה שאין אף מהנדס שיודע איך היא אמורה לעבוד, פשוט מאמנים אותה עד שרואים שזה "מצליח". ועכשיו שאלה פשוטה, האם הייתם עולים על מטוס שלא בנו אותו מהנדסים, אלא ילדים בכיתה ג', אבל, הטיסו אותו מיליוני פעמים ושינו את המבנה שלו, עד שהוא הצליח לטוס בלי ליפול.
בדיוק זהו העניין, אין בן אדם שיודע למה המערכת קיבלה החלטה כזאת ולא אחרת. זה לא משהו שניתן "לדבג" אותו, גורם ההפתעה בו הוא דומיננטי מאוד, אנו מחליפים את האמון בבני אדם שכל אחד ואחד מהם אחראי על המשבצת שלו הפרטית, באמון במשהו שאיננו אנושי כלל (והוא גם לא בקטיגוריה של חוקי הטבע שההכרה האנושית תופסת אותה) ההנחה שהמחשב חושב כמוני, היא לא נכונה, לא שמעתי איש שטוען כך. אז אם איננו יודעים אם המחשב חושב כמונו, איך נוכל לתת בו אמון? מערכת השיקולים שלו נסתרת לחלוטין, ולכן הכרח הוא שכל החלטה של המחשב, תעבור בדיקה אנושית גם כן, מה שמוביל אותנו כעת לשאלת השאלות, האם מכונית אוטונומית דרגה 5 (הדרגה הגבוהה ביותר, ללא כל התערבות אנושית) תהיה או לא תהיה??? תשובה, [size=200:k5rxiqax]לא!!![/size:k5rxiqax] אני חוזר שוב, [size=150:k5rxiqax]מכונית אוטונומית דרגה 5 לא תהיה[/size:k5rxiqax]. יהיו כלי עזר שונים ומשונים, שיעזרו לנהג אבל לא יחליפו אותו לחלוטין. אז לכל הנהגים שפחדו לאבד את משכורתם, כרגע לא נשקפת סכנה.
מה כן אפשרי? מכוניות שלא פועלות על בינה מלאכותית, אלא על מחשוב ותיכנות מסורתי, והן מחוברות לרשת, ונוסעות בכביש מיוחד למכוניות ללא נהג, זה אפשרי. אבל רגע... זה דורש פריסת תשתיות עצומת מימדים, מי הולך לשלם על זה בדיוק???? אלון מאסק??? אולי.

פורסם במקור בפורום CODE613 ב02/09/2017 21:38 (+03:00)

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

http://web.macam.ac.il/~tamil/psychology/4language.htm

http://www.calcalist.co.il/local/articles/0,7340,L-3415756,00.html

http://www.ovzap.net/whorf/index3b.html

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

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

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

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

2. ענייניות ומשמעותיות

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

3. בהירות

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

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

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

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

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

שמות של פעולות, אף הן יכולות לייצג מגוון היבטים:

הפעולה עצמה (בדרך כלל כשם ראשוני): כגון שלוף, הגדר וכדומה.

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

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

הבה נעבור לדוגמאות:
נניח שיש לנו תלמידים שצריך להצמיד להם חונכים, אם למשל יש שגרה שתפקידה לצרף תלמיד לחונך, הייתי קורא לה: AttachStudentToTeacher למה? כי השגרה תפקידה רק לבצע פקודה, ולכן הכי נכון לקרוא לה כשם הפקודה שאותה היא מבצעת.
אולם אם יש אובייקט שמכיל את המידע אודות התלמיד והחונך, הייתי קורא לו כך: StudentByTeacher האובייקט הזה זהו שמו האמיתי והראוי לו, הואיל והוא מייצג את המידע הזה, השם הזה מתאים למיכל של מידע, שמכיל את המידע הרצוי.
ואם יש לי פונקציה שאמורה להחזיר לי ערך של תלמיד לפי מורה הייתי קורא לה: GetStudentByTeacher המילה Get (תמצאו את זה בלי סוף בפונקציות של מייקרוסופט) אומרת שאתה רק "מקבל" את הערך, אולם האובייקט הזה לא "מכיל" את הערך. וזה חשוב מאוד להבדיל בין אובייקטים לפונקציות.
מצד שלישי, לפעמים יש לנו פונקציה שעושה עבודה של שגרה, אולם היא מחזירה לנו True או False בסוף רק כדי שנדע אם הפעולה הצליחה או נכשלה מסיבות כלשהן כגון כללי אימות. במקרה כזה הייתי קורא לפונקציה בשם של שגרה AttachStudentToTeacher ולא בשם של פונקציה, וכל כך למה? הואיל והערך שהיא מחזירה איננו מכיל את המידע שהשם שלה מייצג, אלא את המידע לגבי הצלחת הפעולה שלה. ראוי להתייחס אליה כשגרה לכל דבר.

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

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

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

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

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

בהצלחה לכולם ושנה טובה.

פורסם במקור בפורום CODE613 ב02/09/2013 17:10 (+03:00)

@נתנאל

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

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

פורסם במקור בפורום CODE613 ב10/09/2017 09:40 (+03:00)

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

@CHAGOLD

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

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

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

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

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

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

פורסם במקור בפורום CODE613 ב12/08/2017 21:22 (+03:00)

@avr416

אני עדיין משתמש בwebstorm, מבחינתי הוא נותן ייתרון של השלמה אוט' מליאה, שלא מצאתי בצורה טובה בVS CODE (יש לו השלמה, אבל לא באותה רמה..) - אני מדבר על JS.

הוא נותן באותה רמה, ואם חסר לך באנגולר או משהו יש לך הרחבה
@avr416

כמו כן, הוא דואג לכל ההזחות והקריאות של הקוד

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

מעיר לך על רווחים מיותרים, חוסר ב; וכדו' - ג"כ לא מצאתי בVS CODE

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

העבודה עם git הרבה יותר נוחה לי בweb storm - מבחינת מעקב אחר כל השינויים והכל.

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

אבל אכן, גם לVS יש יתרונות שאין בweb storm למשל F12 מעביר אותך לפונקציית המקור, מה שעדיין לא מצאתי בwebstorm (אני עושה את זה עם חיפוש של שם הפונקציה.

web storms תומך בזה CTRL+B ודווקא באנגולר הוא עושה את זה יותר טוב מ VS CODE.

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

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

פורסם במקור בפורום CODE613 ב10/08/2017 11:13 (+03:00)

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

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

פורסם במקור בפורום CODE613 ב20/07/2017 18:55 (+03:00)

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

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

יש כאן איזה גאון עם תשובה?

פורסם במקור בפורום CODE613 ב14/05/2017 15:01 (+03:00)

למה לא להרים שרת HTTP וזהו. תתקשר איתו באקסס במה שאתה רוצה.

פורסם במקור בפורום CODE613 ב22/05/2017 00:44 (+03:00)

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

פורסם במקור בפורום CODE613 ב21/03/2017 16:28 (+02:00)

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

פורסם במקור בפורום CODE613 ב17/01/2017 00:13 (+02:00)

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

פורסם במקור בפורום CODE613 ב06/10/2016 12:04 (+03:00)

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

פורסם במקור בפורום CODE613 ב23/09/2016 15:20 (+03:00)

@דוד ל.ט.

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

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

פורסם במקור בפורום CODE613 ב20/09/2016 05:57 (+03:00)

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

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

בשביל מה הצבא צריך כאלו מטוסים??? אכן תלוי מה המטרות שלך.

פורסם במקור בפורום CODE613 ב17/12/2016 19:43 (+02:00)