לגלישה באתר בגירסה המותאמת לסלולאר
| הוספת הודעה
הגדרות תצוגה

הגדרות עץ הודעות

מאפייני צפייה

הצג טקסט בתצוגה
הצג תגובות באופן
עדכן
2167121,671 עוקבים אודות עסקים

פורום עבודה בהיי-טק

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

הנהלת הפורום:

אודות הפורום עבודה בהיי-טק

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

לצפיה ב-'מה אתם אומרים על פלטפורמות ה- Low-Code?'
מה אתם אומרים על פלטפורמות ה- Low-Code?
16/10/2019 | 13:12
24
291
ע"פ גרטנר: 
“By 2024, low-code application development will be responsible for more than 65% of application development activity.
 
האם בחברה שלכם מיישמים תשתיות פיתוח שמצריכות מינימום כתיבת קוד ויותר לוגיקה ע"י גרירת אובייקטים וסקריפטים קטנים?
 
האם אתם גם רואים את הגידול בשימוש בתשתיות האלו גם לאפליקציות Enterprise גדולות? 
עבודה בהיי-טק >>
לצפיה ב-'זה לא תחום מחוללי היישומים שחוזר על עצמו עוד פעם?'
זה לא תחום מחוללי היישומים שחוזר על עצמו עוד פעם?
16/10/2019 | 22:55
8
177
ניסו את זה כבר בשנות התשעים. הצפי היה שממש עוד מעט לא יתכנתו עם טקסט יותר ורוב המתכנתים יזדקקו להכשרה פשוטה יותר. טרם קרה
עבודה בהיי-טק >>
לצפיה ב-'וגם אז גרטנר כתבו אותו דבר '
וגם אז גרטנר כתבו אותו דבר
17/10/2019 | 09:08
7
146
בתחילת המלניום עבדתי בקבוצה שפיתחה פלטפורמה כזו באחת מחברות התוכנה הגדולות בעולם. 20 שנה אחרי ואנחנו עדיין ממשיכים לקודד ולקמפל. אבל לעולם אין לדעת.
עבודה בהיי-טק >>
לצפיה ב-'מאז הגיעו לשיפור "משנה מצב" בתחום הבינה המלאכותית'
מאז הגיעו לשיפור "משנה מצב" בתחום הבינה המלאכותית
17/10/2019 | 09:19
6
153
 
זו טכנולוגיה שלא היתה שמישה בתקופת מחוללי היישומים (התאוריה כבר היתה קיימת, אבל החומרה לא איפשרה שימושים פרקטיים יותר מפיענוח אוטומטי של המיקוד על גבי מכתבים בדואר של ארה"ב).
 
יכול להיות שכבר עכשיו יושבות חברות סטארטאפ ב-stealth mode ומפתחות את "הדור החדש" של מחוללי היישומים תוך שימוש בטכנולוגיות החדשות להתגבר על הבעיות שחסמו את מחוללי היישומים בעבר.
 
נ.ב. במקרים נקודתיים כבר השתמשו בסוג מסויים של מחוללי יישומים כדי להחזיק מפתחים בעלי הכשרה חלשה יותר. הדוגמא הידועה ביותר בארץ היא....... אמדוקס. קבוצה בתוך החברה פיתחה "מחולל יישומים" יעודי למערכות ה-billing שלהם, וזה מה שאיפשר לחברה להחזיק מאות מפתחי תוכנה בתפקידי קסטומיזציה, שבהם אנשים בעיקר כותבים ביטויים רגולריים, קבצי xml וכדומה, ואחר כך לא מוצאים עבודה בשוק.
עבודה בהיי-טק >>
לצפיה ב-'אף אחד לא אמר שאין מקום לכלים האלה'
אף אחד לא אמר שאין מקום לכלים האלה
17/10/2019 | 10:04
5
128
עובדה שהם קיימים ועובדים טוב כבר עשרות שנים, לא רק באמדוקס.
אבל התחזיות שכלים כאלה יחליפו פיתוח מסורתי בהיקפים גדולים הוא מופרך בעיניי.
 
מסכים איתך שהתפתחויות למידת מכונה למשל, יכולות להציב תחרות מאתגרת למתכנת האנושי.
אבל מצד שני, נראה שתחום הUX התפתח במקביל גם הוא. פעם יכולת להסתפק בתוכנה עם UI מיקרוסופטי וכולם היו מרוצים וביכולת עיבוד של היום יש מצב שתוכנה יכולה לייצר אפליקציה טובה בסטנדרט של שנות ה90 כמעט ללא תכנות יד אדם.
 
יוצא לי הרבה לנתח דרישות לקוח למערכות שונות. כמתכנת ובטח כקבלן, תמיד יש את הרצון הזה למחזר, להמציא פתרון גנרי, איזו פלטפורמה שאוכל לגלגל מפרוייקט לפרוייקט ולגרוף ממון רב.
 
זה אף פעם לא עובד. יכולת הדמיון וההמצאה האנושית עולה על כל אלגוריתם ואפילו דרישות צנועות של לקוח לא טכני מצליחות לצאת לגמרי מכל גבולות התבניות ה"רגילות" (לא שיש כזה דבר "רגיל").
למיטב ידיעתי האלגוריתמים הלומדים מתבססים על תבניות. לא הצלחתי לזהות ב20 שנות עבודה תבניות מספיק ברורות בפיתוח אפליקציות שתאפשר לתוכנה ללמוד אותן. אמנם זו רק תחושת בטן אבל תחושת בטן של איש מקצוע מנוסה שווה לא מעט.
זו דעתי.
עבודה בהיי-טק >>
לצפיה ב-'אני לא אהיה מופתע אם AI תחליף חלק ניכר מהמתכנתים'
אני לא אהיה מופתע אם AI תחליף חלק ניכר מהמתכנתים
17/10/2019 | 15:59
4
113
פעם אמרו שמחשב לא ייכול לשחק שח מט, התוכנות של היום הם כנראה יותר טובות מכל שחקן אנושי. אבל אז המשחק go היה נחשב קשה יותר למחשב ושנים מחשבים שיחקו go יחסית גרוע, ואז באה איזה חברה ופיתחה משהו שניצחה את אלוף העולם. אפילו זיהוי דיבור לפי מה שהבנתי הגיע לתפקוד ברמה זהה לזו של אדם.
 
חלק מהמשימות האלו מאוד קשות ברמה שרובנו לא נצליח לבצע אותם גם אחרי שנים של אימונים אינטנסיבים ברמה הכי גבוהה שיש, לא קשה להאמין שמחשבים יוכלו לפתח המון תוכנות יחסית פשוטות עם מעט אינפוט מבני אדם (מה שיפחית את הדרישות על כוח האדם ויפחית את הצורך בבני אדם ויוריד משכורות).
 
בקיצור עוד סיבה לא רעה (לדעתי) לחסוך כסף.
עבודה בהיי-טק >>
לצפיה ב-'מחשבים טובים בפתרון בעיות מוגדרות היטב (שח, גו)'
מחשבים טובים בפתרון בעיות מוגדרות היטב (שח, גו)
17/10/2019 | 16:04
3
128
הם גרועים ביותר בבעיות לא מוגדרות שהתוצר המבוקש מהן לא ברור.
כדי להחליף מתכנת במחשב צריך לאפיין בעייה ברמה שמחשב יכול להבין - עבודה שמכונה, על פי רוב, ״תכנות״.
עבודה בהיי-טק >>
לצפיה ב-'האפיון הוא בדרך כלל חלק יחסית קטן מהעבודה'
האפיון הוא בדרך כלל חלק יחסית קטן מהעבודה
17/10/2019 | 16:17
116
לפחות מהניסיון היחסית קצר שלי.
 
זה עדיין ייכול להביא להפחתה רצינית בצורך במתכנתים.
 
וכבר עכשיו יש שימוש מסחרי ב"Chatbot" מה שייכול להפחית עוד יותר את הצורך אם הם ימשיכו להתפתח.
עבודה בהיי-טק >>
לצפיה ב-' בדיוק'
בדיוק
17/10/2019 | 17:21
91
מחשב יכול לנצח אדם בשחמט, במסחר בבורסה, בזיהוי קולי ואפילו בנהיגה. כשיש חוקים ברורים, בעיות מוגדרות, פתרונות מוגדרים, ומטרה ברורה. אין פתרון ל"אפליקציה טובה" זה דומה יותר ליצירת אומנות וסט האפשרויות הוא עצום.
עבודה בהיי-טק >>
לצפיה ב-'היה פעם סטריפ ב-xkcd על כך שהמתכנתים יתכנתו את התוכנות'
היה פעם סטריפ ב-xkcd על כך שהמתכנתים יתכנתו את התוכנות
<< ההודעה הנוכחית
18/10/2019 | 08:38
131
שיביאו לסיום עבודתם.
 
אני מנסה לחפש את זה בגוגל אבל לא מוצא את המילים המתאימות...
 
עבודה בהיי-טק >>
לצפיה ב-'להקשיב לניתוחים של גרטנר בענייני טכנולוגיה זה כמו להסתמך על'
להקשיב לניתוחים של גרטנר בענייני טכנולוגיה זה כמו להסתמך על
17/10/2019 | 15:36
135
יעקב ברדוגו להבנת הפוליטיקה בישראל.
 
לענינינו:
 
1.זה כבר קרה - אתרי נחיתה, תדמית, e-commerce, בלוגים, אתרי מובייל פשוטים כבר אין צורך במפתחים.
 
2. מה זה המטריקה הדבילית הזאת ״of application development %״
 
עבודה בהיי-טק >>
לצפיה ב-'תכנות ויזואלי קיים גם בסביבת פיתוח כמו VS '
תכנות ויזואלי קיים גם בסביבת פיתוח כמו VS
18/10/2019 | 17:27
12
125
שאת ה UI אפשר לבנות על ידי גרירת אוביקטים  לתוך חלון  כמו כפתורים תיבת טקסט  וכו ואת הקוד שמטפל ומגיב לארועים ב UI יש לכתוב בשפה רגילה כמו ++C   ו C# 
(  ה UI הזה מוגדר בחלק של ה resources ).
 
אני לא אוהב לבנות ככה UI זה נראה לי הרבה  פחות גמיש לשינויים  ודי מיגע , יותר נוח לבנות את הקוד בצורה טקסטואלית , למשל שצריך לבנות מערך של כפתורים אז פקודת for פשוטה עושה את זה יופי. 
עבודה בהיי-טק >>
לצפיה ב-'אוי ווי... כבר דיברנו על זה!'
אוי ווי... כבר דיברנו על זה!
20/10/2019 | 13:19
11
96
ראשית, מה שאתה מתאר אינו "תכנות וויזואלי".
למרות ש-MS אהבו לקרוא לכלים שלהם Visual לפני עשור או שניים, והם עדיין אוהבים את זה, בפועל התווית כמעת למגרי ריקה מתוכן.
 
תכנות וויזואלי הוא שאת הקוד עצמו - הלוגיקה, אתה לא צריך לכתוב, אלא גורר אובייקטים גרפיים שמייצגים מבנים ידועים מראש.
 
יש שפה חוצת פלטפורמות לזה:
 
יש אפילו גרסה שלה למיקרו בקרים סטייל ארדואינו, שם כל רכיב חומרה מיוצג כאובייקט.
 
כמובן, זה לא נועד ליישומים של ממש, אלא יותר ללימוד, ובעיקר לילדים.
 
לגבי בניית UI, אין דבר טיפשי יותר היום מבלנות UI בקוד.
אל תיקח את זה כעלבון אישי, אני לא קורא לך טיפש, אתה פשוט לא מהתחום.
 
כשבונים אפליקציה ללקוח, אפליקציה אמתית שהולכת למשתמשי קצה, ולא איזו תוכנה שרק צריכה להציג נתונים טכניים מרכיב חומרה ייעודי שהוא המוצר העיקרי, ה-UI הוא הכל.
 
הוא צריך להיראות טוב! עם אנימציות, עם תמונות שכל אחת במקומה, מעברים, גלילות, משיכות, וכו'.
 
לנסות לבנות מסך שנראה טוב בקוד, זה כמו משחק "הצמד את הזנב לחמור" (לא יודע אם יש גרסה ישראלית לזה).
 
אתה מנסה לנחש מיקומים, לדמיין אותם בראש, ואז לתכנת מספרים קשיחים.
במקום פשוט לעצב את ה-UI עם כלים מתאימים.
 
אני אפילו לא נכנס לזה שהיום כל בניית UI היא "יחסית" או "אדפטיבית" כי צריך להתחשב בהמון סוגי מסכים.
 
בוא ניקח את הדוגמה הפשוטה שלך:
למה לכל הרוחות שתבנה כפתורים בלולאה? מניין יגיע טקסט לכל כפתור ואיך תצמיד לו את הקוד הרלוונטי?
 
אם יש אלמנט בממשק שמכיל יותר מ-3 אופציות, הוא כמעת אף פעם לא יהיה אוסף כפתורים.
הוא יהיה משהו דינאמי כמו תפריט או רשימה, משהו שבכל UI מודרני מטופל ע"י אובייקט יעודי, שמקבל "מקור מידע" ולפי אותו מקור מידע מייצר את האפשרויות הדרושות בזמן ריצה בלי שתצטרך לבנות אחת אחת בקוד עם לולאה משלך.
 
יותר מזה, הוא ידאג להתעדכן אוטומטית כשמקור המידע משתנה.
 
אני יודע שאתה תקוע עם כלים של MS משנות ה-90, עבדתי איתם לפני שנים ואני יודע שהם מייצרים הרגלים רעים, אבל הם גם מייצרים ממשק שהיום נחשב למכוער ולא מקצועי.
 
זמנם תם, ממליץ לך בחום לפתח הרגלים חדשים!
עבודה בהיי-טק >>
לצפיה ב-'זה בהחלט בשימוש לישומים של ממש labview או simulink ועוד רבים'
זה בהחלט בשימוש לישומים של ממש labview או simulink ועוד רבים
20/10/2019 | 14:14
24
לצפיה ב-'נכון זה לא בדיוק תכנות , אבל לדעתי יותר נוח לבנות'
נכון זה לא בדיוק תכנות , אבל לדעתי יותר נוח לבנות
20/10/2019 | 14:58
9
61
את UI על ידי תכנות טקטואלי,  לא רואה בעיה עם חישב מיקומים , זה קצת מתמטיקה על הפיקסלים ואפשר לעשות את זה עם מיקומים יחסיים  ( כך שאם אתה מחליט להזיז קבוצת פקדים אז כל האחרים זזים בהתאם ).
נכון זה לפעמים קצת ניסוי ותעיה, אז מה, מקמפלים מריצים מסתכלים על התוצאה  ואם צריך משנים בקלות את הקוד ושוב מקמפלים ומריצים ...
 
והנה דוגמה לקוד שבונה מערך כפתורים אחד מתחת לשני
 
 #define NUMOFBUTTONS 10

char *butontext[NUMOFBUTTONS] ={"func1","func2" ...};
char  *tips[NUMOFBUTTONS]={"this button do function 1", "this button do function 2",...};
unsigned int style[NUMOFBUTTONS]={ PUSH_BUTTON, PUSH_BUTTON ...};
FUNC *func[NUMOFBUTTONS] = {func1,func2};

int x=20, y=88, width=90, high=25; // location of the topbutton and size of each button
int space_between_buttons =30;
for int n=0; n<NUMOFBUTTONS; n++)
{
   pbutton[n] = new MyButton(x,y,width,high, butontext[n],tips[n],func[n],style[n] );
   y+=space_between_buttons;

}
 
קל מאד לשנות את מיקום מערך הכפתורים, את הטקסטים עליהם, את מספר הכפתורים .... באמצעות שינו הקוד.
 
וגם יש לי ביד מערך של מצביעים לכל הכפתורים למקרה שצריך לעשות עליהם פעולות בהתאם לארועים ( לאפשר\לא לאפשר , לשנות טקסט עליהם, אפילו להזיז או לשנות גדול ).
 
 
עבודה בהיי-טק >>
לצפיה ב-'ומה קורה כשאתה צריך לייצר ממשק בכמה שפות?'
ומה קורה כשאתה צריך לייצר ממשק בכמה שפות?
20/10/2019 | 16:15
8
62
נניח שהמשתמש רוצה ששפת הממשק תהיה בהתאם לשפה שהוא בחר במערכת הפעלה?
 
אפילו MS בשנות ה-90 כבר המציאו resources לטפל בדברים כאלה
 
מה קורה אם לכל פתור יש יותר מאפיינים מאשר מיקום, גודל, וטקסט?
 
אני רואה שאתה משתמש בבנאי מפלצתי שקולט 8 פרמטרים, זה כבר בעייתי אבל מה אם היה לך יותר?
נניח שלכל כפתור היה צריך צבע אחר, היה צריך להוסיף תמונה, ועוד...
כמה פרמטרים אתה מוכן לתת לבנאי שלך לפני שהקוד הופך ללא קריא?
 
כשמתכנת אחר צריך לקלוט את הפרויקט, איך הוא יודע למצוא היכן קוד שלך שבונה UI?
ואיך הוא מתרגם את הקוד חזרה למה שהוא רואה על המסך כדי להבין מה לשנות או אפה להוסיף?
 
מה קורה עם תוכנות רציניות שלוקח הרבה זמן לקמפל, או תוכנה שבנוסף לקימפול צריך להוריד למכשיר עליו היא תרוץ (למשל טלפון), ואז כל "ניסוי וטעיה" לוקח הרבה זמן?
 
איך אתה בודק כיצד נראית התוכנה שלך על מסכים עם רזולוציה שונה?
 
בדוגמת קוד שהצגת גם חסר קוד שמכניס את הכפתורים להיררכיית חלונות.
זה עוד דבר שנורא קשה להבין כשבונים ממשק בקוד - מי יושב בתוך מי, מי הבן של מי ומי האבא וכו'.
 
אגב, איך אתה עושה מתמטיקה של גודל טקסט?
אלא אם אתה משתמש בפונט עם רוחב אות קבוע, משהו מפוקסל סטייל מאה שעברה, קשה להעריך בדיוק של פיקסל כמה מקום תתפוס מחרוזת נתונה.
יותר מזה, אם המשתמש במקרה שינה גודל של פונט ברירת מחדל במערכת, למשל מסיבות נגישות, אתה אוכל אותה ובגדול.
 
עם כל הכבוד, מה שאתה מדגים פה זו צורת עבודה שהתחילה להיכחד כבר בשנות ה-90.
 
היא בזבזנית, משום שהיא מכריחה מתכנת לייצר ידנית ולתחזק קוד ייעודי פר יישום, שחלקו הנכבד הוא קריאות חוזרות לפונקציות קבועות עם פרמטרים משתנים (כגון יצירה ושיוך פקדים).
 
היא מייצרת קוד קשה לתחזוקה, משום שאין דרך לבודד כמו שצריך את אפיון הממשק משאר הקוד, ומשום שהקוד עצמו שיוצר את הממשק אינו מתאר את הממשק, ואפילו יש סיכוי טוב שיפסיק להיות מסודר (לפי היררכיית פקדים) אחרי כמה איטרציות.
 
היום יש כ"כ הרבה כלים לחסוך את הצרות האלה ולעבוד בצורה נכונה, מסודרת, וחסכנית, שפשוט כואב לראות מישהו מגן על שיטה כזו...
עבודה בהיי-טק >>
לצפיה ב-'אם צריך שפות שונות אז השמות מוגדרים '
אם צריך שפות שונות אז השמות מוגדרים
20/10/2019 | 18:50
7
70
ב resources
ואין בעיה להוסיף עוד פרמטרים לבנאי כמו צבע  הכפתור, צבע הטקסט וכו וכמובן שאחד הפרמטרים צריך להיות מצביע לחלון האב שמכיל את הכפתורים ( בדוגמה  לא פירטתי את כל הפרמטרים שיש ).
האפליקציה שלנו רצה על דסקטופ ולא על טלפונים סלולרים אז הרזולציה היא בד"כ גדולה מ 1024X768 , והפונט הוא בגדול קבוע מסוג  ariel שנמצא בכל מערכת הפעלה ( אגב יש פונקציה שמחזירה את רוחב הטקסט בפיקסלים עבור כל סוג של פונט בהינתן  סטרינג).
 
קל למצוא את הקוד של כפתור מסוים , מסתכלים על UI ועושים חיפוש על השם שמופיע על הכפתור  ( או על הטיפ שלו ) בתוך הפרויקט ( ב VS יש אופציה לעשות חיפש על הפרויקט או על עץ או על  ה solution כולו  ), לחיצה על  F12 על שם של פונקציה מקפיצה את העורך למימוש שלו או להצהרה עליו בהגדרת המחלקה וכו.
 
אני חושב שזה גישה טובה אולי הכרחית להריץ כל פעם את האפליקציה ולראות איך זה נראה באמת ואיך זה מגיב לארועי משתמש, בד"כ מדובר בקימפול של קובץ בודד  ( את הקוד משנים  רק בקובץ cpp אחד ולא ב .h שמשותף להרבה קבצים כך שהקימפול לא לוקח הרבה זמן, לפעמים גם צריך לגעת בקובץ h שמכיל את הגדרת מחלקת החלון שמכיל את הפקדים ).
 
אני לא רואה סיבוך גדול בשיטה הזאת , בד"כ יש פונקציה אחד במחלקת החלון שתפקידה לבנות את ה UI עם שם קבוע , ולשם ניגשים כאשר רוצים לעשות שינויים. והקוד שמציב את הפקדים על החלון הוא לא מסובך סה"כ קריאה לבנאים של הפקדים אולי בתוך לולאת for .
 
 
 
 
עבודה בהיי-טק >>
לצפיה ב-'אמאל'ה...'
אמאל'ה...
20/10/2019 | 19:36
6
65
אז אצלכם אפילו לא מפרידים את ה-GUI לקבצים נפרדים עם איזה naming convention?
 
אני אשכרה צריך לבצע חיפוש על טקסט כדי למצוא כפתור???
מה אם הטקסט על הכפתור הוא "OK"???
 
התיאורים שלך מזכירים לי יותר מידי את הצורה בה עבדתי כשלראשונה למדתי לעבוד עם ++Visual C גרסה 6 אי שם בסוף שנות ה-90.
 
זה היה סביר לפרויקטים אישיים קטנים, וגם לא הכרתי שום דבר יותר טוב מאז, אבל היום זה נשמע לי כמו להניע רכב עתיק בעזרת מנועלה מקדימה במקום לסובב מפתח.
זה עובד, אבל זה איום ונורא!
 
אתה לא רואה סיבוך גדול כנראה משום שמעולם לא היית צריך לבנות ממשק מעוצב באמת, וגם משום שאם משתמשים באותן פונקציות כל הזמן מתרגלים לריבוי פרמטרים.
 
בפועל, לא לטעות בבנאי עם 10 פרמטרים שרובם מאותו טיפוס זו אומנות, שכל כשל קטן בה מזמין באגים.
 
אגב, Ariel הוא לא פונט בגודל קבוע.הוא פונט בגודל משתנה זה בדיוק הנקודה שלו.
האות i והאות W לא תופסות אותו מקום.
והוא לא נמצא "בכל מערכת", הוא רק נמצא בכל גרסה של Windows.
 
אם חלילה ללקוחות שלכם יימאס להשתמש בה והם יחליטו לזוז, זו תהיה עוד צרה ב-porting.
 
מצד שני, יש לי תחושה שמבנה הקוד אצלכם הוא כזה שכל תזוזה משמעותית תהיה שכתוב מלא...
עבודה בהיי-טק >>
לצפיה ב-'ב GUI מסובכים אי אפשר להפריד באמת בינו לבין הלוגיקה'
ב GUI מסובכים אי אפשר להפריד באמת בינו לבין הלוגיקה
20/10/2019 | 21:55
5
70
הלוגיקה מעורבת חזק בתוך ה GUI, היא מעדכנת כל מיני פקדים לפי כל מיני מצבים ומודים שמשתנים בצורה דינמית , מאפשר\לא מאפשרת \מסתירה\מציגה כל מיני פקדים בזמן אמת. מציגה טקסטים שונים  על המסך.
 
לא אמרתי שאריאל זה פונט בגודל קבוע אבל הוא נמצא בכל מערכת הפעלה של חלונות ( אגב גם QT שרץ על לינוקס תומכת בו ) .ידוע שהרוחב של כל אות שונה ועדין אותה פונקציה יודעת להסתדר איתו ולהחזיר במדויק את האורך שהמחרוזת תתפוס בפיקסלים ( יש טבלה שמכילה את הרוחב של כל אות ).
 
אם רוצים לאפיין את כל הפרמטרים של כפתור  חייבים להשתמש בבנאי עם הרבה פרטמרים-  אי אפשר לברוח מזה , אפשר כמובן לצמצם את זה לפרמטר אחד שהוא מבנה שמכיל הרבה שדות עם הפרמטרים שזה אולי יותר קל לדיבוג , אבל עדין הבנאי מקבל בסופו של דבר הרבה פרמטרים  .
עבודה בהיי-טק >>
לצפיה ב-'הפוך גוטה, הפוך'
הפוך גוטה, הפוך
21/10/2019 | 00:33
4
69
ביישום מודרני יש מספר רכיבים מופרדים.
ה-GUI עצמו מתואר ע"י שפה משלו (לרוב XML), ונבנה אוטומטית ע"י ספרייה ייעודית שיכולה להיות חלק ממערכת הפעלה, או יכולה להיות צד ג' כמו QT שהזכרת.
 
(אגב - אין קשר בין ספריית QT לפונט אריאל או כל פונט אחר, היא תתמוך בכל TTF)
 
המידע ל-GUI מסופק ע"י שכבה נפרדת, בהתאם למקור וסוג המידע, ולבסוף יש את שכבת הלוגיקה ממש.
 
בלי הפרדה ראויה אי אפשר היה "לשחות" אפילו ביישומי טלפון רציניים, על תוכנה שולחנית גדולה אין מה לדבר בכלל.
 
אז כן - לך יש פונקציה שמחשבת אורך מחרוזת.
לי אין צורך לקרוא לפונקציה כזו. לפקד כבר יש קוד שיטפל בזה בשבילי.
 
ולא, ממש לא חייבים להשתמש בבנאי עם הרבה פרמטרים.
יש מספר דרכים לברוח מזה.
 
כאמור, כשעובדים עם פריימוורק GUI נורמלי, לא צריך בנאים בכלל.
מתארים את הפקדים במבנה XML פשוט וקריא.
 
אם בכל זאת מייצרים דינמית, אפשר (ומומלץ) להשתמש בתבנית "Builder" שזה אובייקט שבונה את הפקד, אחרי שהוא מקבל את כל המאפיינים שלו אחד אחד דרך פונקציות ייעודיות (כדי שיהיה ברור מה כל פרמטר עושה).
 
וכן - לפעמים לא יזיק לאגד מספר פרמטרים רלוונטיים במבנה במקום לדחוף אחד אחד.
עבודה בהיי-טק >>
לצפיה ב-'האם אותו קובץ XML שמגדיר את ה GUI הוא חלק מהאפליקציה'
האם אותו קובץ XML שמגדיר את ה GUI הוא חלק מהאפליקציה
21/10/2019 | 18:47
3
55
שמסופקת ללקוח יחד עם קובץ ההרצה EXE ? אם ככה יש פה סיכון גדול  שהקבצים לא יהיו מתואמים, הלקוח יתקין קובץ EXE חדש בלי לעדכן את ה XML או ההיפך.
בשיטה  שלי  ה EXE כולל כבר את הקוד של בנית ה GUI 
 
ועוד חיסרון שלוקח יותר זמן לבנות את הGUI כי יש להעלות קובץ XML מהדיסק ולפרסר אותו.
 
ואיך בונים את ה GUI ? גוררים פקדים עם העכבר לחלון ואז לוחצים עכבר ימני מקבלים תפריט שבוחרים "מאפיינים" ואז מופיע טבלה עם שדות של כל הפרמטרים של הפקד ( גדול ומיקום, צבע, צבע טקסט , שם , שם הפונקציה .....) ומציבים ערכים
 
ועכשיו חוזרים על התהליך המיגע עם הפקד השני (טוב  סביר שאפשר לעשות קופי פסט מהפקד הראשון ולעדכן רק את הפרמטרים השונים במאפיינים ) , בכל מקרה נקרא לי יותר מייגע מאשר כתיבת לולאת FOR
 
 
עבודה בהיי-טק >>
לצפיה ב-'ניתן לקמפל את קובץ בתור resource בדיוק כמו'
ניתן לקמפל את קובץ בתור resource בדיוק כמו
21/10/2019 | 21:00
2
68
שעושים עם קבצי תיאור דיאלוג או אייקונים השייכים לאפליקציה.
 
חוץ מזה, אם אתה מספק את התוכנה שלך ללקוח בצורה חורנית - ע"י שליחה של קבצים בתפזורת, במקום עם מתקין מסודר, יש לך כנראה בעיות גדולות הרבה יותר מאשר אי התאמה בין EXE ל-XML.
 
אף פעם לא עבדת על תוכנה שכללה יותר מ-EXE בודד?
רוב התוכנות היום הן לא קובץ אחד בכל מקרה.
 
לכל ערכת כלים יש עורך GUI משלה.
אפשר כמובן גם לכתוב את ה-XML ידנית, או לערוך ידנית אם צריך משהו "עדין" או מיוחד שהעורך הוויזואלי לא מספק.
 
למשל, ב-Android Studio המעבר בין ייצוג גרפי לייצוג טקסטואלי של חלון הוא בצורה של TAB. זה קובץ אחד שפתוח עם שני טאבים - אחד גרפי, אחד טקסטואלי.
 
מן הסתם, כשאתה יוצר פקד, הוא כבר מקבל מאפיינים ברירת מחדל.
 
בערכות GUI מתקדמות (זה קיים ב-Android וב-iOS לא סגור לגבי QT ו-GTK) ניתן להגדיר "style" אלמנט עיצוב, שאחרי זה ניתן להצמיד לכל פקד, והוא יקבע אוסף של מאפיינים ביחד.
 
למשל, יש לך בתוכנה כפתורים מסוימים עם טקסט ירוק עבה ומסגרת, ששונים מכפתורים אחרים?
תגדיר פעם אחת את העיצוב, ותקבע אותו כמאפיין בודד לכל כפתור כזה.
 
זה נראה לך מייגע כי כנראה אתה עכשיו כותב ממשקים מאוד פשוטים, וגם כי אתה היחיד שצריך לגעת בהם.
 
מבחינתי, ואני בטוח שלא חסר מפתחים שיסכימו איתי, לחפש לולאת FOR עלומה כי צריך פתאום שינוי באיזה כפתור באפליקציה, זה סיוט מספיק גדול כדי להצדיק שכתוב פרויקט.
 
ובכלל, זה לא מיגע לזכור 10 פרמטרים שצריך לקבל כל בנאי?
כמה פעמים היה לך באג בגלל שהתבלבלת בסדר שלהם?
 
אפילו ב-VS 6 כבר היית טבלת מאפיינים מסודרת שמאפשרת גם לראות (במקום לזכור) באלו מאפיינים הפקד תומך, גם לערוך בצורה מסודרת כשאתה רואה את שם המאפיין שאתה רוצה לקבוע, ואפילו לקבל אופציות למאפיינים שיכולים לקבל טווח מצומצם של ערכים (למשל כיווני הצמדת טקסט).
 
יש מקרים בודדים יוצאי דופן בהם משתלם או הגיוני לשחק עם פקדים דינאמית בתוך הקוד כמו שאתה עושה, אבל בתור שיטה, זה קושי מיותר ומתכון לבאגים.
 
וכל זה עוד לפני שהגענו לאפשרויות הצמדה אוטומטית של פונקציות טיפול באירועים או מקורות מידע...
עבודה בהיי-טק >>
לצפיה ב-'לפעמים מעדכנים ללקוח רק חלק מהחבילה'
לפעמים מעדכנים ללקוח רק חלק מהחבילה
28/10/2019 | 10:49
1
23
כדי לחסוך בהעברת חבילה גדולה מידי שלא עוברת דרך email , למשל עם השידרוג הוא רק בקובץ DLL בודד אין טעם לשלוח את כל החבילה שוב, אבל אז צריך להזהר שאין בעית תאימויות שונות.
 
לגבי ריבוי פרמטרים לבנאי , חלק ניכר מהפרמטרים האחרונים מוגדרים עם ערכי ברירת מחדל  וברוב המיקרים אין צורך לשנותם למשהו אחר ולכן הקריאה לבנאי היא רק עם מעט פרמטרים.
 
עבודה בהיי-טק >>
לצפיה ב-'אז דיזיין המערכת אצלכם עובד כך שלא משנה מה'
אז דיזיין המערכת אצלכם עובד כך שלא משנה מה
28/10/2019 | 16:30
22
יש לפתח תוצרים שמסוגלים לעבור במייל?
 
אולי לא שמעתם, אבל Google Drive נותנים 15GB חינם לכל דורש, ואם אתם פוחדים ש-Google יגנבו לכם את התוכנה היקרה מפז, אפשר תמיד להשתמש ב-ZIP עם ססמה.
 
עבודה בהיי-טק >>
לצפיה ב-'מי שכותב כתבות כאלה לא ממש מבין מה זה "תכנות":'
מי שכותב כתבות כאלה לא ממש מבין מה זה "תכנות":
20/10/2019 | 13:26
124
יש סיבה שקוראים לכלי תכנות "שפות תכנות".
כי אלה באמת שפות - דרך כתובה להסביר למחשב מה אתה רוצה ממנו.
 
תכנות גרפי הוא כמו "פיקטוגרפים" - כתב התמונות בו השתמשו המצרים הקדמונים (ותרבויות אחרות).
 
אלפי שנים של התפתחות שפות כתובות הוכיחו ששימוש בכמות אותיות מצומצמת שמייצרת מילים שמתחברות למשפטים היא שיטה עדיפה הרבה יותר, גם אם במבט חטוף היא נראית מסובכת יותר.
 
אומנם אימוג'י עובדים קשה כדי להחזיר את הגלגל אחורה, אבל תרם ראיתי יצירה ספרותית שנכתבה כולה עם אימוג'י או יותר אימוג'י מאשר טקסט.
 
וכך אני גם לא מצפה לראות יישום מקצועי שנכתב בדרך וויזואלית במקום קונבנציונלית.
 
מבחינתי, הטענה בכתבה שווה ערך לסרטון הזה:
עבודה בהיי-טק >>

הודעות אחרונות

16:58 | 03.12.19 קוטקס אובה אולטרה
22:01 | 30.11.19 user32
19:14 | 30.11.19 סימבה8881
21:26 | 29.11.19 luis13
13:45 | 28.11.19 nik19864
19:45 | 13.11.19 איתי 91
13:57 | 04.11.19 JuniorDeveloper
10:42 | 04.11.19 tomer12112
16:40 | 30.10.19 elkr

חם בפורומים של תפוז

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

מקרא סימנים

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