במאמר זה אשתף כיצד תוכלו להימנע מכמה מהטעויות שעשיתי כשנודע לי על Electron.js? ♂️. אני מקווה שזה עוזר!
הערה : זה לא יהיה הדרכת קידוד, אלא דיון על המנות האישיות שלי.
לפני כמה חודשים החלטתי להתמקד יותר בבניית המוצר הצדדי שלי, taggr . קיבלתי השראה לבנות אותו בגלל כמה תמונות יש לי במחשב.
לאלו מאיתנו ששומרים על גיבוי של התמונות שלהם, האוספים האלה לרוב נהיים כה גדולים ומורכבים שהם הופכים למשרה מלאה לניהול. שילוב של תיקיות ותיקיות משנה עשוי להכיל גיבויים לתמונות מיידיות, תמונות ברזולוציה גבוהה מהטיול שלך בבאלי, החתונה של דודך או מסיבת רווקים בשנה שעברה.
תמיד לשמור על אוספים כאלה מסודרים זה מייגע (תאמין לי, ניסיתי כבר שנים). זה גם קשהכדי לגלות את הצילומים שאתה הכי אוהב, מוסתרים עמוק בתוך התיקיות.
אז taggrהיא אפליקציית שולחן עבודה הפותרת את הבעיה. זה מאפשר למשתמשים לגלות מחדש את הזיכרונות שלהם תוך שמירה על פרטיותם .
אני בונה את taggr כיישום שולחני בין פלטפורמות. כאן אשתף חלק מהדברים שלמדתי על פיתוח אפליקציות חוצה פלטפורמות עם Electron.js שהלוואי שהכרתי מההתחלה. בוא נתחיל!
רקע כללי
לפני שאני מציג את המבקרים שלי במסע המתמשך הזה עם אלקטרון, אני רוצה לתת קצת יותר רקע על עצמי ועל הדרישות של taggr .
כל מפתח מגיע מרקע אחר, וכך גם הדרישות של היישומים שהם מפתחים.
הקשר בין הבחירות שעשיתי עבור פרויקט זה עשוי לסייע למפתחים עתידיים לבחור את הכלים הנכונים על פי צרכיהם ומומחיותם (במקום מה שמופיע שם - GitHub? אני מסתכל עליך)
כאמור, מההתחלה ראיתי בעיני רוחי את taggr כיישום חוצה פלטפורמות. האפליקציה תבצע את כל החישובים הנדרשים לעיבוד מקדים ולמידת מכונה בצד הלקוח בשל ההתמקדות בפרטיות.
כהצגה של אדם אחד, רציתי להיות מסוגל לכתוב את האפליקציה שלי פעם אחת ולשלוח אותה למערכות שונות מבלי לאבד את שפיותי.
מהצד שלי, אני מהנדס קצה מאוהב באינטרנט וב- JavaScript. עבדתי בעבר עם Java ו- C #, אך אני נהנה מהגמישות שהאינטרנט מספק ומהמערכת האקולוגית התוססת שלו.
לאחר שחוויתי ממקור ראשון את הכאב של שימוש בכלים כמו Eclipse RCP לבניית אפליקציות בצד הלקוח, ידעתי שאני לא רוצה לעבוד שוב עם הטכנולוגיה הזו.
בקיצור, דרישות הערימה שלי עבור taggr הסתכמו במשהו כמו הבא:
- הוא אמור לספק תמיכה חוצה פלטפורמות, באופן אידיאלי ברמת המסגרת. ?
- זה אמור לאפשר לי לכתוב את הקוד פעם אחת ולהתאים לכל פלטפורמה במידת הצורך. ? ️
- זה אמור לאפשר גישה ליכולות למידת מכונה , ללא קשר לסביבת המארח, ללא התקנת זמן ריצה ספציפי. זה צריך להיות ללא כאבים להתקין. ?
- אם הדבר אפשרי, עליו להשתמש בטכנולוגיות אינטרנט . זה יהיה נהדר למנף את הידע הקיים שלי. ?
כפי שאתה יכול לראות, הדרישות אינן קוראות כך: עלי להשתמש בתגובה עם Redux, תצפיות ו- WebSockets . מדובר בפרטי יישום ברמה נמוכה יותר, ויש להחליט עליהם מתי ואם עולה הצורך.
בחר את הכלי המתאים לעבודה במקום לבחור ערימה מההתחלה, תוך התעלמות מהבעיות העומדות בפנינו.
אז, לאחר גוגל זועם, החלטתי לנסות את אלקטרון. לא השתמשתי בעבר במסגרת זו, אך ידעתי שחברות רבות משתמשות בה בהצלחה במוצרים כמו Atom, VS Code, Discord, Signal, Slack ועוד.
קוד פתוח ועם תאימות מחוץ לקופסה למערכות האקולוגיות JS ו- Node (אלקטרונים נבנים באמצעות Chromium ו- Node), Electron.js היה כלי אטרקטיבי לעבודה.
לא אפרט יותר מדי לגבי שאר הערימה, מכיוון ששיניתי שוב ושוב חלקי ליבה (התמדה ותצוגת שכבות) בעת הצורך, והוא נופל מחוץ להיקף מאמר זה.
עם זאת, ברצוני להזכיר את Tensorflow.js, המאפשר אימון ריצה ופריסת דגמי ML ישירות בדפדפן (עם WebGL) וב- Node (עם כריכות C), מבלי להתקין זמני זמן ספציפיים עבור ML במארח.
אז חזרה לאלקטרון - מתוך מחשבה שזה מושלם, הכיף התחיל. ??
די לדבר על הרקע. בואו נצלול לטייק אווי.
1. להתחיל בקטן (ואיטי)?
זה לא מושג חדש, אבל כדאי להעלות אותו מעת לעת. רק בגלל שיש המון פרויקטים מתחילים מדהימים עם אלקטרונים, זה לא אומר שאתה צריך לבחור אחד מיד.
לַחֲכוֹת. מה?
איטי הוא חלק, וחלק הוא מהיר. אמירה של חיל היםעם הנוחות מגיעה המורכבות
בעוד שמתחילים אלה כוללים אינטגרציות שימושיות רבות (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), יש להם גם את הבעיות שלהם.
בתור טירון חדש באלקטרונים, החלטתי ללכת על תבנית רזה הכוללת את היסודות ל'יצירה, פרסום והתקנת אפליקציות אלקטרונים 'ללא תוספת פעמונים ושריקות. אפילו לא Webpack בהתחלה.
אני ממליץ להתחיל במשהו שדומה לאלקטרון-זיוף כדי להתחיל לעבוד במהירות, אתה יכולהגדר את גרף התלות והמבנה שלך על מנת ללמוד את חבלי האלקטרון.
כאשר הבעיות מגיעות (והן יגיעו), יהיה לך טוב יותר אם תבנה את פרוייקט המתנע המותאם אישית שלך במקום לבחור אחד עם סקריפטים של +30 ננומטר ותלות +180 מלכתחילה.
עם זאת, ברגע שתרגישו בנוח עם הבסיס של אלקטרונים, אתם מוזמנים להגביר את המשחק עם Webpack / React / Redux / TheNextHotFramework. עשיתי את זה באופן הדרגתי ובמידת הצורך. אל תוסיף מאגר נתונים בזמן אמת לאפליקציית ה- todo שלך רק בגלל שאתה קורא מאמר מגניב על זה איפשהו.
2. לבנות את האפליקציה בקשב? ♂️
זה לקח קצת יותר זמן להגיע נכון ממה שאני שמח להודות. ?
בהתחלה, אולי מפתה לערבב את קוד ה- UI וה- Backend (גישה לקבצים, פעולות מעבד מורחבות), אך העניינים מורכבים די מהר. ככל שהיישום שלי גדל בתכונות, בגודל ובמורכבות, שמירה על בסיס קוד אחד של ממשק משתמש + Backend סבוך הפכה מסובכת יותר ונוטה לטעויות. כמו כן, הצימוד הקשה על בדיקת כל חלק בבידוד.
בבניית אפליקציית שולחן עבודה שעושה יותר מדף אינטרנט משובץ (גישת DB, גישה לקבצים, משימות אינטנסיביות למעבד ...), אני ממליץ לחתוך את האפליקציה למודולים ולהפחית את הצימוד. בדיקת יחידות הופכת למשב רוח, ויש דרך ברורה לקראת בדיקת אינטגרציה בין המודולים. עבור taggr , עקבתי באופן רופף אחר המבנה שהוצע כאן.
נוסף על כך, יש ביצועים . הדרישות וציפיות המשתמש בעניין זה עשויות להשתנות באופן פרוע בהתאם ליישום שאתה בונה. אבל חסימה של ההליך הראשי או העיבוד עם שיחות יקרות לעולם אינה רעיון טוב.
3. לעצב עם מודל ההשחלה בראש?
לא אפרט כאן יותר מדי - אני פשוט מכפיל בעיקר את מה שמוסבר להפליא במסמכים הרשמיים.
במקרה הספציפי של taggr , קיימות פעולות אינטנסיביות רבות במעבד, GPU ו- IO. כאשר מבצעים פעולות אלה בשרשור הראשי או העיבוד של אלקטרון, ספירת ה- FPS צונחת מ- 60, מה שהופך את ממשק המשתמש לתחושה איטית.
Electron מציעה מספר חלופות להורדת פעולות אלה מהשרשורים הראשיים והמעבירים, כגון WebWorkers, Node Worker Threads, או מופעי BrowserWindow. לכל אחד יתרונותיו ואזהרותיו, ומקרה השימוש העומד בפניו יקבע איזה מהם מתאים ביותר.
לא משנה באיזו אלטרנטיבה תבחרו לפריקת הפעולות מהחוטים העיקריים והמעבדים (במידת הצורך), שקול כיצד יהיה ממשק התקשורת . לקח לי זמן להמציא ממשק שהייתי מרוצה ממנו, מכיוון שהוא משפיע מאוד על אופן הבנייה והפונקציה של היישום שלך. מצאתי מועיל להתנסות בגישות שונות לפני שאבחר.
לדוגמה, אם אתה חושב שממשק העברת הודעות WebWorkers לא יכול להיות הקל ביותר לפיתרון באגים, נסה את comlink.
4. לבדוק ❌, לבדוק ❌ ולבדוק ✔️
חדשות ישנות, נכון? רציתי להוסיף זאת כנקודה האחרונה, בגלל כמה 'בעיות' אנקדוטליות שהתמודדתי לאחרונה. מקושר חזק לנקודות הראשונות והשנייה, בניית פרויקט המתנע המותאם אישית שלך וטעויות בשלב מוקדם תחסוך לך זמן ניפוי ניפוח יקר בהמשך הפיתוח.
אם פעלת אחר ההמלצות שלי לפיצול ממשק המשתמש וה- Backend של האפליקציה למודולים עם ממשק נקי בין השניים, הגדרת בדיקות אוטומטיות של יחידות ויחידות צריכה להיות קלה. עם התבגרות היישום, ייתכן שתרצה להוסיף תמיכה גם לבדיקות e2e.
חילוץ מיקום GPS? ️
לפני יומיים, תוך יישום תכונת חילוץ מיקום ה- GPS עבור taggr , ברגע שבדיקות היחידות היו ירוקות והתכונה עבדה בפיתוח (עם Webpack), החלטתי לנסות את זה בסביבת הייצור.
בעוד שהתכונה עבדה היטב בפיתוח, היא נכשלה כישלון חרוץ בייצור. מידע ה- EXIF מהתמונות נקרא כבינארי ועובד על ידי ספריית צד שלישי. בעוד שהמידע הבינארי נטען כהלכה בשתי הסביבות (נבדק עם הבדל), ספריית הצד השלישי נכשלה בעת ניתוח נתונים כאלה במבנה הייצור. סלח לי, ??
פתרון : גיליתי שהגדרות הקידוד בסביבות הפיתוח והייצור שקבעו Webpack אינן זהות. זה גרם לנתונים הבינאריים לנתח כ- UTF-8 בפיתוח אך לא בייצור. הבעיה תוקנה על ידי הגדרת כותרות הקידוד המתאימות בקבצי ה- HTML שנטענו על ידי אלקטרונים.
תמונות פאנקיות?
בעת מניפולציה ועבודה עם תמונות, אתה עשוי לחשוב שאם JPEG 'פשוט עובד' במחשב שלך, זה JPEG תקף. לא נכון .
תוך כדי עבודה עם ספריית עיבוד התמונות של Node בצורה חדה , שינוי גודל של כמה תמונות JPEG קרס את היישום. לאחר בחינה מקרוב, הסיבה הייתה תמונות JPEG שגויות שנוצרו על ידי קושחת סמסונג. ? ♂️
פתרון : הגדרת גבולות שגיאה משופרים באפליקציה (למשל חסימת ניסיון לתפוס), צבוט במודול הניתוח JPEG וחשוד בהכל. ? ️
סיכום
מערכות האקולוגיות של Node ו- JavaScripts פורחות, עם כלים חזקים רבים שנוצרים ומשותפים מדי יום.
כמות האפשרויות מקשה על בחירה בנתיב ברור להתחיל בבניית אפליקציית Electron החדשה והמעולה שלך. ללא קשר למסגרות שבחרת, אני ממליץ להתמקד בדברים הבאים:
- התחל בקטן והוסף מורכבות באופן הדרגתי.
- בנה בקפידה את האפליקציה שלך , שמור על backend וממשק משתמש נוגע למודולריזציה.
- תכנן עם מודל ההשחלה , גם כשבונים אפליקציות קטנות.
- בדקו ובדקו שוב , כדי לתפוס את רוב השגיאות בשלב מוקדם ולחסוך כאבי ראש.
תודה שנשארת עד הסוף! ?
taggr הוא יישום שולחני חוצה פלטפורמות המאפשר למשתמשים לגלות מחדש את הזיכרונות הדיגיטליים שלהם תוך שמירה על פרטיותם . Open-alpha מגיע בקרוב ל- Linux, Windows ו- Mac OS. אז עקוב אחר טוויטר ואינסטגרם, שם אני מפרסם עדכוני פיתוח, תכונות חדשות וחדשות.