פיתוח בסביבת חלונות (WINDOWS)

[BravoMan]

הדוגמה הקונקרטית הכי גדולה שנתקלתי בה

(מבחינת כמות הקבצים שהיה צריך לשנות) היא אותה שורה ארורה שהצגתי בתחילת ההודעה הקודמת.
&nbsp
עבור MS, זו הדרך המקובלת והמומלצת למנוע מקבצי כותר להיכלל פעמיים (או יותר) וליצור שגיאות קומפילציה.
אבל מסתבר, שהיא לא חלק משום תקן, ולכן אם עוברים לקומפיילר שלא מתוצרת MS, יש לשנות כל קובץ h בפרויקט ולהחליף הוראה זו במקרו עוטף.
&nbsp
עוד דוגמה נהדרת, שאולי לא כ"כ נפוצה בקוד פרודקשין, אבל בכל זאת קיימת ומתועדת היטב היא אוסף היצורים הזה:
https://msdn.microsoft.com/en-us/library/w40768et.aspx
&nbsp
מישהו ב-MS החליט, שהיות והחלק מהפונקציות הסטנדרטיות נחשבות ללא בטוחות לשימוש, הם יציעו גרסאות משלהם לפונקציות האלה, עם תוספת קטנה לשם הפונקציה.
&nbsp
רק מה - למרות שהדבר הזה נראה כאילו הוא שייך לספריה הסטנדרטית של השפה, בפועל מי שישתמש בו בקוד יהפוך את הקוד לתלוי פלטפורמה.
&nbsp
והנה דוגמה שאפילו לא קשורה לתכנות:
שולח קובץ טקסט פשוט במייל, המקבל מתלונן שהקובץ כולו בשורה אחת.
&nbsp
מכיר את התופעה?
הכלל בגלל שסוף שורה מוגדר שונה בין מערכות הפעלה שונות.
&nbsp
אה, רגע נזכרתי בעוד משהו:
בזמנו, התייעץ פה משתמש לגבי בעיה שנוצרה לו כשהוא ניסה לשלוח ספריה דינמית ללקוח (קובץ DLL).
&nbsp
אז דובר על LIB והצורך בו.
משהו שמפתחי MS מורגלים לשימוש בו, אבל בפועל הוא קובץ מיותר, שאאל"ת קשור היסטורית לכך ש-MS יצרה calling convention שונה בין מערכת ההפעלה שלה בפועל לכלי הפיתוח שלה עצמה.
&nbsp
אז מה? זה פרט של מערכת הפעלה, או פרט שכל מפתח אפליקציה שרוצה להשתמש בספריה חיצונית צריך לדעת?

 

[ipv6]

אלה דוגמאות חלשות יחסית

prgama once נתמך על ידי preprocessor-ים רבים, כולל בלינוקס.
GCC ו-CLANG
https://en.wikipedia.org/wiki/Pragma_once
זה לא משהו איזוטרי שמיקרוסופט המציאו.
גם אם קימפלת בקומפיילר שלא תומך בזה, זה ממש לא סיפור לשנות את זה בכל הקוד עם find-replace. זאת משימה שנחשבת קשה אצלכם?!
שינויים ברמה הזאת נדרשים גם כשעוברים מקומפיילרים בתוך אותה מערכת הפעלה GCC-->CLANG למשל.

לגבי פונקציות "בטוחות בווינדוס" - בווינדוס ה-good practice (לפחות לפי הספר של ריכטר \ msdn) הוא לעבוד עם פונקציות של מיקרוסופט ולא פונקציות ספריה סטנדרטיות, כנ"ל עם טיפוסים של ווינדוס DWORD \ TCHAR וכן גם עם הפונקציות ה"בטוחות" של מיקרוסופט.
הפונקציות שציינת באות לפתור בעיה אמיתית (קלט שיותר גדול מהמקום שהקצת לו -->buffer overflow), מיקרוסופט לא אשמים שהשם מבלבל אותך. בסוף גם את הבעיה הזאת לא קשה לתקן ולי יצא לעשות שינויים על פני פרויקט גדול (מאד).

לא צריך להיות מומחה ללינוקס ולא לווינדוס בשביל לפתור את הדברים האלה.

 

[יבגניי34]

אכן דוגמאות חלשות, וה״ביקורת״ שלך חלשה באותה מידה.

אפשר ״לשנות את כל הקוד עם find-replace״? ראשית pragme once# ו- ifdef# סטנדרטי זה *לא* אותו דבר. שנית, תצטרך איכשהו לייצר שם ייחודי ל header שאתה מגן עליו.
מסובך? לא. ״לשנות את זה בכל הקוד עם find-replace״? גם לא.

כל ה״דיון״ הזה קצת הזוי ומטופש. זה לא סוד שמי שרוצה לכתוב ++C פורטבילי צריך לשים זאת בראש מעייניו משורת הקוד הראשונה. וזה בדיוק אומר לא pragma once ולא wintypes.h ולא pthread.h ולא לחבר שמות ספריות עם ״/״ ועוד אלף ואחת איסורים. מה בדיוק חדש או מעניין פה, לא ברור.

 

[ipv6]

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

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

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

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

 

[יבגניי34]

pragma once# מתייחס לנתיב הקובץ בתור המזהה הייחודי שלו

משמע אם יש לך אותו הקובץ פעמיים תחת ספריות שונות - הוא יכלל פעמיים למרות pragma directive#.

 

[ipv6]

יש פה דוגמא נחמדה

https://stackoverflow.com/questions/1143936/pragma-once-vs-include-guards
(התשובה עם רייטינג 22 - From a software tester's perspective)

אבל זה לא משנה את התמונה:
1. החלפת -#pragma ב-guardian רק משפרת את המצב
2. זה מקרה דיי איזטורי. לא נתקלתי במצב שבו בכוונה קוראים ל-2 קבצים באותו השם ואם עובדים ככה כנראה שמראש לא היו משתמשים ב-pragma
3. גם את זה קל לתפוס ולתקן.

 

[BravoMan]

כל דוגמה תראה חלשה כשאתה מסתכל עליה תאורטית

וזורק פתרונות תאורטיים.
&nbsp
בפועל, כשיש לך פרויקט בגודל בינוני עם עשרות קבצי כותר מפוזרים בין מספר ספריות, ואתה צריך להעביר אותו מגרסה ישנה של כלי MS שכבר בעייתי להתקין על עמדות פיתוח חדשות לגרסה קצת ישנה של gcc שעדיין לא תומכת ב-pragma once, אבל כן תומכת בפלטפורמה אליה הקוד נועד, פתאום הדוגמה נראית מאוד "חזקה".
&nbsp
אני לא מכיר שום כלי Find / replace שיודע להוסיף לך שורה בסוף הקובץ בנוסף להחלפה.
&nbsp
אתה יכול להכיר לי אחד שעונה על הדרישות הבאות:
1. יכול להחליף שורה אחת בשתי שורות
2. מאפשר להכניס פרמטר אוטומטי של שם קובץ להחלפה
3. יודע להוסיף גם שורה בסוף הקובץ ולא רק במקום המוחלף.
&nbsp
אם הייתי "יודע לינוקס" אז, כמו שאני יודע לינוקס היום, יכולתי לכתוב סקריפט awk ולהריץ אותו עם find כדי למכן את המשימה.
לצערי, אז עוד לא "ידעתי לינוקס" ברמה הנחוצה...
&nbsp
מצחיקה אותי הגישה "מיקרוסופט לא אשמים שהשם מבלבל אותך", אז מי אשם בדיוק?
מי בחר את השמות?
&nbsp
לא אמרתי שהבעיה ש-MS מנסה לפתור היא לא בעיה אמתית, או שהפתרון לא נחוץ.
טענתי רק, שמפתח שמשתמש בפתרון כזה, צריך להיות מודע היטב למגבלות הפתרון, והדמיון הרב בשמות הפונקציות לא עוזר לקדם את המודעות הזו.
&nbsp
ועוד נקודה מצחיקה בתגובה שלך:
"בווינדוס ה-good practice (לפחות לפי הספר של ריכטר \ msdn) הוא לעבוד עם פונקציות של מיקרוסופט ולא פונקציות ספריה סטנדרטיות"
&nbsp
אתה מתווכח איתי שמפתח לא צריך להכיר לעומק מערכת הפעלה, ובו בזמן טוען שהדרך הנכונה היא לעבוד דווקא עם API ספציפי של מערכת הפעלה במקום עם הכלים הסטנדרטיים של השפה???
אתה מבין שבעצם הראית כרגע בעצמך שמפתח טוב כן צריך ידע מעמיק, אפילו מעבר ל-power user אם הוא רוצה לממש good practice (לפחות ב-windows)?
&nbsp
אבל בוא ניקח כאב ראש אחר (בשפות C ו-++C):
שימוש בספריות דינמיות.
&nbsp
האם לדעתך ניתן לפתח אפליקציה משמעותית בלי להשתמש בספריות צד ג' בכלל?
ואם לא, האם לדעתך מפתח יכול להסתדר עם ספריות בלי להבין איך מערכת ההפעלה הספציפי עליה הוא עובד מטפלת בכל נושא ה-loader / dynamic linker?
&nbsp
אגלה לך סוד קטן:
התהליך שונה מאוד בין לינוקס ל-Windows, אפילו בנקודה הפשוטה של "איפה ה-DLL \ SO שלי לכל הרוחות?"

 

[BravoMan]

TL;DR

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

 

[bismark1]

זה לא מה שאמרתי

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

אני לא מבין איך זה קשור לפורטביליות של ++C.

 

[ipv6]

זה לא תאורטי

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

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

מה שכתבתי לגבי ווינדוס נועד להסביר למה קיימים היצורים האלה [1].
אם אתה כותב דרייברים, user space מאד נמוך בווינודס, תוך כדי שימוש כבד ב-winapi \ native api כמובן שאתה צריך להכיר את מערכת ההפעלה.

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

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

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

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

 

[BravoMan]

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

שוב - אפשר לפתור הכל.
אם יודעים איך - אז הפתרון קל מאוד.
(שמת לב שכל שפות הסקריפט שפירט אינן טכנולוגיות MS, ולא מותקנות מראש על מערכת Windows מצויה?)
&nbsp
כשדיברתי על "להכיר לינוקס", לא דיברתי על להפוך למפתח kernel ולדעת איך דברים ממומשים מתחת למכסה המנועה וגם לא על ירידה לרמת האסמבלי וניסיון להתחרות בקומפיילר עם אופטימיזציות.
&nbsp
דיברתי בדיוק על הכרות עם shell וחבריו כמו awk ו-find שיהפכו הרבה "מניפולציות על קבצי טקסט" למאוד פשוטות.
&nbsp
כל מה שכתבת על חברות ואקזיטים - לא רלוונטי.
במקרה, אני עובד בחברה שרוב העובדים בה לא ממש מבינים מה היא "מערכת הפעלה".
זו חברה שמצד אחד מייצרת מוצרים מאוד הייטק, ומצד שני מה שהיא באמת מוכרת זה שירותים שמבוססים על המוצרים האלה, אז יחס מהנדס -> לא מהנדס בחברה מאוד מוטה

&nbsp
העניין כאן איזה ידע דרוש לך בתור מפתח כדי לבנות את הקריירה שלך.
אם אתה רוצה לבנות על משרות ספציפיות שידרשו רק את ידע הדומיין שלך, ויתנו לך להשלים את כל השאר בזמן העבודה או יצוותו אליך מישהו שיטפל בזה - סבבה.
&nbsp
גם מתכנת ML צריך להבין למה פתאום התוכנה שלו לא רצה או לא מצליחה לפתוח קובץ כשזה קורה בגלל בעיות path \ permission \ LD\ DLL hell או דברים דומים.
&nbsp
ייתכן מאוד שהוא ירצה לדעת מה זה make ו-configure ולמה הוא צריך לבחור עם איזו תוכנה לערוך את הקוד שלו במקום שכל העסק ייפתח בדאבל קליק על sln וגמרנו...
&nbsp
[1] ההרגשה שלך מוטעית.
ללינוקס יש מלכודת דומה שנקראת gnu extensions.
זה בא לידי ביטוי כשרוצים לבנות את ה-kernel מ-source, אבל מפתח אפליקציות יכול להימנע מזה.
&nbsp
למעשה, עכשיו הזכרת לי ששם עשו משהו דומה עם asm - הוא הופיע כהרחבה לפני c99, ואז נכנס לתקן, מה שעלול ליצור בלבול לא קטן.
&nbsp
לפחות ההרחבות האלה דורשות feature macro כדי שהקומפיילר יסכים לקבל אותן...
&nbsp
אין לי בעיות עם הרחבות לא סטנדרטיות לשפות כל עוד ברור למתכנת מתי הוא משתמש בהרחבה, ולא חובה להשתמש בהרחבה הזו לאפליקציה שאינה low level.
&nbsp
gcc מעולם לא ניסה להמליץ לי על ההרחבות שלו.
VS לאומת זאת, בכל פעם שהוא רואה scanf או חברים, מקפיץ Warning שממליץ לעבור לגרסה המיקרוסופטית.

 

[ipv6]

יש define שאפשר להגדיר כדי לא לקבל את הwarning ב-VS

 

[choo]

הדברים הללו מכערים את הקוד היטב....

 

[ipv6]

הלינוקס שאני התכוונתי אליו

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

תאר לך מבנה נתונים דמוי map (תן מפתח, קבל ערך) שמבוזר על פני כמה Node-ים.
אתה יכול לגשת לכל אחד מהם, לתת מפתח ולקבל את הערך, ללא קשר באיזה Node פיזי ה-Value נשמר.
עיקר הפיתוח התרכז בלעשות את המבנה הנתונים, מהיר, קומפקטי ועמיד לנפילות (HA). מאחורי הקלעים רצו כמובן כמה process-ים תקשרו דרך פרוטקול כזה או אחר, קראו מהדיסק בצורה X וקראו/כתבו לזכרון משותף בצורה Y.
רב הבשר בעבודה (פיצ'רים חשובים, משימות) נסובו סביב הארכיטקטורה של המבנ"ת הזה (איך נשמרים הערכים? איזה cache-ים שומרים ולמה וכו'). לדברים שהיית צריך מהמערכת הפעלה (נניח תקשורת עם Node מרוחק) היה בד"כ API שמנע ממך את הצורך להכיר מה קורה מתחת.
(נניח לא הייתה צריך לדעת כמעט כלום על הדרך שבה ה-node-ים מתקשרים. לא את הפרוטוקול ולא את ה-stack שלו).
הבנתי שגם בחברות אחרות בתחום, המצב דומה.

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

ברמת המשתמש קשה לי לשים את האיפה עובר,לדעתי, הקו בין הכרחי-->לעוזר-->רלוונטי. המון אנשים הסתדרו בלי להכיר make בכלל.
גם awk ו-sed נראה לי משהו שמעטים יחסית מכירים ובכל זאת עובדים על לינוקס, כנ"ל לגבי bash שהוא לא בסיסי.

 

[choo]

מההכרות שלי עם תחומים דומים, אי הכרת המערכת מוביל לבאגים ממש

&nbsp
בניהול של KV-store יש כמה דברים בסיסיים מבחינת מבנה מערכת ההפעלה ומבנה החומרה שעליה היא רצה, שחייבים לדעת כדי לכתוב קוד עמיד באמת לנפילות, ובמיוחד אם צריך שהוא יעבוד מספיק מהר. דוגמאות נקודתיות:
&nbsp
א. בכתיבה לדיסק צריך לוודא שמבצעים flush נכון (גם ברמת ספריית ה-I/O וגם ברמת API של מערכת ההפעלה) כדי שהמידע באמת ישב בדיסק. מי שלא מכיר את מנגנון ה-page cache של מערכת ההפעלה, יכתוב קוד שלפעמים יאבד נתונים בזמן הפסקות חשמל או קריסות מערכת הפעלה.
&nbsp
ב. שימוש יתר במנגנון הסינכרון לדיסק יגרום לקריסת ביצועים, ולכן בפועל מקובל לנהל טראנזקציות, שנפילות ביניהן תאבדנה את הפקודות האחרונות. לחליפין - ישתמשו ברכיב NVRAM או בזכרון מגובה סוללה מסוג אחר כדי לנהל את הטרנזקציות הללו.
&nbsp
ג. גם בשימוש ב-NVRAM צריך להכיר את צורת העבודה של ה-cache כדי שהנתונים אכן יגובו ל-nvram ולא ישארו ב-cache (וגם פה שימוש לא יעיל יפגע מאוד בביצועים)
&nbsp
ד. בפרט בעבודה מרובה נימים צריך לדעת כיצד לבצע עידכוני טראנזקציות בצורה אמינה כשמספר חוטים שונים מעדכנים את מבני הנתונים הרלונטיים. זה מתחיל להסתבך במיוחד כשמשתמשים במבני נתונים שהם lockless (ולא תמיד אפשר לקחת מבנה נתונים מוכן מראש), וכשיש באגים בקוד, היכולת להבין כיצד מבני הנתונים האטומיים כתובים (דוגמא קטנה: בלינוקס, בכל mutex רשום מי ה-LWP שמחזיק אותו כרגע, אם קיים. הידיעה של זה יכולה לחסוך הרבה זמן (ולמנוע צורך בכתיבת קוד מעטפת) בדיבוג של deadlocks, למשל.
&nbsp
פרוטוקול התקשורת הוא ממש לא החלק היחיד שנוגע במערכת ההפעלה ובסביבת הריצה של החומרה במערכות מהסוג הזה, וראיתי כיצד ניתן לכתוב באגים קשים לאיתור בגלל אי הכרת המערכת והחומרה.

 

[ipv6]

כמו בדיון לגבי רלוונטיות השכלה אקדמאית

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

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

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

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

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

 

[choo]

לגבי סדרי העדיפויות - אני מסכים

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

 

[BravoMan]

אתה יודע מה?

נזכרתי בדוגמה פשוטה ומצחיקה, שלא הגיע לפרודקשין כי קרתה לי בפרויקט שפיתחתי בעצמי לצורך לימוד:
&nbsp
כתבתי תוכנה די פשוטה שעבדה במצב טקסטואלי במסוף.
רציתי להוסיף לה מגנון ספירת זמן, שיתקדם ויתעדכן על המסך בזמן שהתוכנה ממתינה לקלט מהמשתמש.
&nbsp
על פניו, מקרה פשוט של שימוש ב-tread, שלא מצריך אפילו ידע בסנכרון.
&nbsp
ה-tread הראשי ימתין לקלט כרגיל, ו-tread נוסף ברקע יעדכן בלולאה שעון במקום כלשהו במסך.
&nbsp
השתמשתי בספריות pthread ו-ncurses (כדי שההדפסות יצאו קצת יותר יפות מ-printf פשוט).
&nbsp
כששיחקתי עם הדבר הזה על ה-P4 הישן שלי בעל ליבה אחת ו-2 threads, הכל עבד מעולה.
אחרי שהחלפתי את המחשב הביתי שלי ל-Core i7 בעל 4 ליבות ו-8 threads פתאום גיליתי שכל המסך מתחרבש.
&nbsp
מסתבר, שבמערכת מרובת ליבות, אי אפשר סתם ככה להציק ל-ncurses מכמה thread במקביל בלי להיכנס לצרות, למרות שעל מעבד חד ליבתי, אותו קוד בדיוק עובד תקין...
&nbsp
צר לי, אבל קשה לי להאמין לסיפור שסיפרת על אותו מוצר storatge.
&nbsp
או שהיה לכם צוות נפרד שהתמחה בכל חלק ה-low level שלו, ואתה פשוט לא היית מודע לאותו צוות מספיק כדי להעריך את התרומה שלו, או שהתבססתם על מוצר קיים בתור תשתית.
&nbsp
אפשרות אחרת יחידה שאני רואה כאן, היא שהמוצר לא היה טוב כמו שאתה חושב שהוא היה.
זה לא היה מונע מהחברה להיות מצליחה.
הצלחה כלכלית של מוצר טכנולוגי, לא תמיד קשורה לאיכות שלו. למעשה, יותר מידי פעמים היא לא...

 

[יבגניי34]

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

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

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

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

וכמו שאמר ההוא מעלי - זה נכון לא רק לתחום הזה.

 

[BravoMan]

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

שאין הבדל בין הבעלים של ניק "יבגני" עם י' אחת, לבין "יבגניי" עם 2 י'
יש רק הבדל במצב רוח בו אותו אדם מחליט לכתוב בפורום, ונראה שהפעם היית במצב רוח רע ושכחת להחליף כינוי...
&nbsp
לא נורא

&nbsp
בכל מקרה, #C היא Corss platform כמו שמקסיקני הוא "חייזר":
האמריקני אולי יקרא לו alien אבל זה לא אומר שהוא הגיע מכוכב אחר.
&nbsp
MS תמיד שווקה #C בתור שפה Cross platfrom ומתחרה ל-Java, אבל בפועל #C תמכה, ועד היום תומכת, אך ורק ב-Windows. וזו הסיבה שהיא מעולם לא ניצחה את Java מבחינת רוחב שוק.
&nbsp
עכשיו בטח תרוץ לספר לי על NET core. ואיך MS התחילו לתמוך ב-Linux ולשחרר קוד.
נחמד, אבל לא רלוונטי לקוד שכבר קיים - הוא לא נתמך ולא ייתמך.
&nbsp
הם לא פתחו את הספריות המלאות של NET. או את הקומפיילר המקורי.
&nbsp
הם יצרו משהו חדש באותו שם.
כמה תאימות יש בין זה למה שקיים? לא בטוח, אבל הבנתי שלא הרבה, אם לוקחים פרויקט אמתי ולא סתם איזו הוכחת יכולות.