GUI לדסקטופ או ממשק וובי?

[מדינה קטנה]

GUI לדסקטופ או ממשק וובי?

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

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

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

הסיבות העיקריות לכך שהיינו רוצים ממשק וובי הן אלה:
1. אנחנו לא רוצים להקשות על המשתמשים עם התקנה מסובכת והרבה dependencies.
2. אחד המנחים שם דגש על הממשק ודי בעניין שנשתמש בטכנולוגיות "state of the art". כלומר, בסוף צריך שגם "ייראה מגניב" מספיק, ויש הרגשה שGUI לדסקטופ זה דבר מאוד מיושן. כשניסינו לחפש חבילה מתאימה לפייתון, האפשרויות הכי מומלצות באמת נראו מיושנות מאוד מהרבה בחינות.

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

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

תודה מראש

 

[rj111]

לא רואה בעייה עם ממשק וובי

אפשר לשים שעון חול בהמתנה ולא אמורה להיות בעיה בהעלאת קובץ.
תוכלו להשתמש ב-bootstrap או material design lite בשביל הממשק.
ממשק וובי מאפשר הרצה גם ממובייל אם מממשים ממשק רספונסיבי.

 

[Guy Yafe]

לכו על WEB

היו לכם שתי הסתייגויות מ - WEB:
1. חישובים שייקחו זמן: היום כל טכנולוגיות ה-WEB יודעות לבצע עבודה אסינכרונית ולהציג התקדמות ברקע (ראו דרופבוקס, פייסבוק וכו'). אתם תצטרכו להציג בדף שלכם פס התקדמות שיראה שהקובת בהעלאה, שהחישובים בהכנה (אם אפשר לחלק את החישובים בשביל רזולוציה יותר גבוהה, מה טוב) וכו'.
2. אין בעיה להעלות למערכות WEB קבצים בגודל של ג'יגה בייט ועוד. רוחב הפס משפיע על קצב ההעברה ולא על גודל המידע המקסימלי. כמובן שאם תשימו את המערכת על אותה מכונה, ההעלאה תהיה מאוד מהירה ולא שונה ממערכת "רגילה". מצד שני אם תעלו קבצים דרך מערכת מרוחקת, אמנם ההעלאה תיקח זמן, אבל זה לא שונה ממערכת "רגילה". למעשה מערכת WEB כנראה תעלה את הקבצים בקצב יותר גבוה כי יש לה יכולות דחיסה בנויות.
&nbsp
החסרון היחיד הוא שלמערכות כאלה יש עקומת למידה לא טריויאלית וכנראה תצטרכו צוות נוסף שיבנה אותה.
&nbsp
מצד שני, אתם תרוויחו הרבה טכנולוגיות out of the box, יכולות ליצור UI מאוד יפה, מערכות כאלה סקלביליות מאוד (במידת הצורך תוכלו להוסיף לה משאבים כרצונכם), ואם תרצו להנגיש את המערכת ללקוחות מחוץ למכונה שלכם, יהיה לכם הרבה יותר קל עם מערכת WEB.
&nbsp
בהצלחה
&nbsp

 

[vinney]

עלית על הבעיה העיקרית, אבל היא לחלוטין פתירה

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

&nbsp
לגבי state of the art - זה לא בדיוק מוגדר. לרדוף אחרי הטרנד האחרון והאופנתי זה לא תמיד בריא. אם כי כדי להרשים את המנחה, אולי שווה את זה. אם זה מה שעושה לו את זה, מה כבר אפשר לעשות.

 

[יבגניי34]

עצות קונקרטיות: אם זה יכול להיות וובי, כדאי שזה יהיה וובי.

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

- כן אפשר להעלות 30MB לרשת וזה ייקח בערך 10 שניות.
- אם אתם מתעקשים על אפליקציה: electron זו סביבה מומלצת אם אתה כבר יודעים html

 

[BravoMan]

מהיכרותי עם אנשי הפורום, רוב המשתתפים כאן מפתחים WEB

אז לא בטוח כמה העצות אובייקטיביות.
&nbsp
אבל אני לא הולך לשמש קונטרה, אלא להביא רשימת שיקולים, כי לדעתי אין מספיק מידע על המערכת כדי להחליט על ארכיטקטורה.
&nbsp
קודם כל, צריך לזכור, שתמיד יש אופציה להשתמש בטכנולוגיות Front End של Web לממשק עבור אפליקציה מקומית.
כלומר, במקום ערכה גרפית ל-Python כמו PyGtk תשמשו בדפדפן לממשק.
&nbsp
אבל, אם אתם רוצים לבצע את העבודה על שרת, ולספק Web service שאנשים יגשו אליו, ואתם רוצים את זה מעבר לפרויקט גמר שהמשתמשים בו תהיו רק אתם והמנחה, הנה כמה שיקולים:
&nbsp
1. תחזוקת שרת.
אחסון חינמי לא יאפשר לכם להריץ קוד Python משלכם. תצטרכו להוציא לפחות כמה גרושים מידי חודש על VPS כלשהו.
יש דברים כאלה די בזול, אבל עבור סטודנטים גם בזול יכול להיות מאוד יקר.
&nbsp
2. משאבים:
כמה חישובים במקביל יוכל השרת שלכם לבצע?
אומנם הזכירו כאן שעל מחשב של המשתמש התוכנה עשויה לרוץ לאט, כי לחלק מהאנשים יש מחשבים ישנים שעושים עוד דברים, אבל גם עבור שרת, שהוא בסה"כ סתם מחשב, לשרת במקביל מספר משתמשים ולעשות עבור כל אחד חישוב כבד, לא יהיה פשוט.
&nbsp
כמובן שתמיד אפשר להרחיב את התשתית של השרת, אבל שוב - אם אתם עושים את זה בהתנדבות, מן הסתם לא יהיה לכם כסף לעשות את זה.
תוכנה אפשר תמיד להפיץ, ושכל אחד ימצא לעצמו מחשב חזק מספיק לעבוד איתה.
&nbsp
3. פלט:
מה בדיוק החישוב שלכם יחזיר?
אם זה קובץ בודד, אין בעיה לספק הורדה שלו.
אם מדובר באוסף קבצים, הסיפור מתחיל להסתבך.
או שתארזו אותם ב-zip בצד שרת כדי לספק הורדה אחת, או שתתחילו להפציץ את המשתמש במספר הורדות.
&nbsp
כך או כך, למרות שבתנאי אינטרנט אופטימליים היום העברה של כמה עשרות מגה לא תיקח יותר מידי זמן, היא עדיין תיקח הרבה יותר זמן מאשר עבודה מול אחסון מקומי, גם אם זה האר דיסקט מגנטי ישן.
&nbsp
ומה לגבי שמירת תוצאות?
אם ההורדה נכשלה, האם המשתמש צריך להעלות מחדש, ולהמתין לחישוב מחדש?
אם לא, תצטרכו לנהל חשבונות ולשמור קבצים (מקום בשרת), כדי לאפשר הורדות חוזרות.
&nbsp
מה שמביא אותנו לעוד סעיף תקציבי:
4. רוחב פס.
בד"כ ספקי אחסון אתרים או VPS גובים לפי רוחב פס, כלומר, כמות מידע שהאתר שלכם שולח ללקוחות.
אם גם קבצי הפלט גדולים, ואנשים רבים ישתמשו בשירות שלכם (או מעט אנשים הרבה פעמים), יכולות להיות שם עלויות רציניות.
&nbsp
5. אבטחה ויציבות.
ברגע שמדובר בשירות אינטרנט חשוף לעולם, מישהו כבר ימצא איך להתעלל בו.
לכל הפחות, הוא יוכל להרוס את השירות עבור אחרים, ובמקרה יותר גרוע יוכל לנצל את השרת שלכם למתקפות שונות, הפצת נוזקות, וכו', אם השרת שלכם לא יהיה מוגדר ומאובטח בצורה נכונה.
&nbsp
שוב - אם מדובר רק בהגשת פרויקט ולמנחה לא אכפת, אין בעיה.
אם מדובר במשהו שאתם רוצים לחשוף לעולם, זה סיפור אחר.
&nbsp
האינטרנט קיים כבר כמה עשורים, זה לא "state of the art" ביחס לתוכנה לוקלית על מחשב שולחני.
&nbsp
צריך להבין מה בדיוק הדרישות של המערכת שאתם רוצים לבנות.
להשתמש בכלי מוכן להכנת אינסטולר, לא בהכרח מסובך יותר מאשר לקנפג שרת בצורה נורמלית.
&nbsp
ללמוד מערכת build לא בהכרח מסובך יותר מללמוד framework וובי כזה או אחר.
&nbsp
והנה ראיון נחמד:
תוכנה מופרדת ל-GUI ושורת פקודה, fornt end ו-back end מקומי, כך שמצד אחד משתמש לא טכני מן השורה יוכל להשתמש בה בקלות, ומצד שני מפתחים אחרים יוכלו לבצע אוטומציה, להרחיב פונקציונליות, ולשלב את התוכנה שלכם בלי להיכנס לקוד שלה.

 

[user32]

מדובר בחוויית משתמש. התשובות שקיבלת קצת מקובעות לטעמי

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

כמו האחרים: הייתי ממליץ לך על WEB.
בהצלחה

 

[Grosseto]

לכו על django

בדרך כלל מקובל שישנן שלוש שכבות, שכבת UI, שכבה לוגית , ושכבת DB
&nbsp
כך שניתן להחליף UI וDB בלי הרבה בלאגן

 

[Nuke1985]

תגובה

טוב הרוב פה נוטים לכיוון של ווב, אני אנסה לאזן את הדיון (מצד שני כתבתי אפליקציות native שהם high performance אז אולי אני לא הכי אובייקטיבי).

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

בדרך כלל יש פתרונות בשביל להוריד תלויות , החל מstatic linking ו והוספת shared libraries להתקנה, וגם פתרונות יותר מורכבים כמו appimage או py2exe. אפשר גם לפתח מערכת לעדכונים אוטמטיים, או אם אתם רוצים להתעסק אם משהו שהוא דיי state of the art אפשר להשתמש בflatpak שגם אמור לטפל בבעיה של התלויות וגם לעשות את העדכון מאוד קל.

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

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

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

 

[vinney]

תחנה מקומית יכולה לשמש שרת גם כן

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

 

[Nuke1985]

יש בהחלט טכנולוגיות שמטשטשות את הגבול בין ווב לנייטיב

נכון אפשר להתקין מקומית.

אבל זה עלול להיות בעייתי כי טכנולוגיות מסויימות (כמו נניח rails) לא מותאמות לפיתוח desktop app . למרות שכמו שציינו יש דרכים לייצר אפליקציות desktop בכלים "ווביים" (כמו electron) .

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

 

[vinney]

שרת הוא שרת, "מרוחק" זה לא משהו שמחשב מודע אליו

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

 

[Nuke1985]

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

שזה מה שהדאיג אותם.

 

[vinney]

בין שרת מקומי לבין אפליקציה מקומית לא צריך להיות שום הבדל

לפחות לא משמעותי. להעתיק 30MB מקומית לוקח לכל היותר שניות בודדות.

 

[Nuke1985]

נכון

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

 

[שוקולדשבעיםאחוז]

אתה צודק לגבי כרטיס רשת ו ולגבי 127.0.0.1

עד כמה שידוע לי - כרטיס הרשת לא מעורב.

 

[choo]

נקודה מהותית: חישבו על עתידכם המקצועי

&nbsp
פרוייקט במסגרת לימודי תואר נועד בראש ובראשונה לקדם אתכם, לא לספק ערך למישהו אחר.
&nbsp
בשוק ההיטק בארץ כיום פיתוח UI מתבצע בעיקר בטכנולוגיות web (או טכנולוגיות מובייל) והרבה פחות בטכנולוגיות desktop. לפיכך, ובעיקר אם יש לכם עניין כלשהי לבצע עבודת UI בתעשיה, כדאי לכם לבחור להשתמש בטכנולוגיות web מקובלות בשוק, ולא בטכנולוגיות דסקטופ. צריכה להיות סיבה *מאוד מאוד* טובה כדי להשתמש בטכנולוגיות דסקטופ כיום.
&nbsp
מה יותר קל? לדעתי פיתוח באמצעות טכנולוגיות דסקטופ קל יותר (אבל הידע המקצועי שלי בתחום די מיושן). אבל הקל הזה במקרה הזה יהפוך את הפרוייקט לפחות תורם לכם מבחינת קורות חיים בתעשיה.

 

[יבגניי34]

 

[אוהב להתווכח]

 

[שוקולדשבעיםאחוז]

לא רק בארץ

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