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

חיפוש נוסף בגוגל הביא לי את הפרויקטים הבאים:

• https://github.com/chemdemo/deskshell תאריך העדכון האחרון שלו הוא 4 שנים..
• https://github.com/Mikej81/WebRDP מעודכן יחסית, 4 חודשים.. נראה טוב.

@שואף אמר בבעייה דחופה במסד נתונים:

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

למעשה, שיניתי הInterclassement לutf8mb4_general_ci ועכשיו הוא מקבל סמיילים דרך הPHPMYADMIN, אבל הסקריפט PHP שלי עדיין לא מצליח להכניס לו סמילים בDATABASE

אתה צריך להגדיר utf8mb4_unicode_ci

@google3 אשאל אותך כך: יצא לך לחוות תקלות וdowntime שנבע מטעויות אנוש שיכלו להימנע אילו מישהו מקצועי יותר היה שולט בכל התשתיות שלך?
מה לדעתך כמות העובדים שאתה צריך להגיע אליה כדי להתחיל לעבוד מסודר? (רמז: אחד.)

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

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

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

חשבתי על פתרון נוסף, אם כי לא הייתי בוחר בזה כהדרך ה"נכונה"
תוכל להריץ docker build על השרת ישירות מהלפטופ, כלומר הcontext (קבצי הקוד שלך) מועלה לשרת, והבילד בפועל מתבצע בשרת ככה שפעולות כמו הורדת ספריות וכו מרוויחים ממהירות האינטרנט של השרת.
אני משתמש בזה לסביבת טסטים של פרויקט מסוים, וזה נח.
א. docker context create develop --docker "host=ssh://aaron@develop" (אחרי שכמובן הגדרתי ב~/.ssh/config את פרטי החיבור)
ב. docker context use develop
ג. docker compose up -d --build

בונוס: התוסף של vscode לcompose, בלי לצאת מהעורך קוד והעלית גרסה..
https://code.visualstudio.com/docs/containers/docker-compose

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

@שואף
למה שעשית קורים in-context training, ולדעתי משתמשים בזה יותר ויותר.
למשל הצורה שבה בינג מכניס מידע מהאינטרנט לתוך התשובות שלו.

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

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

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

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

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

@צבי-ש
https://developers.facebook.com/docs/whatsapp/cloud-api/get-started

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

@צבי-ש
אם 30$ לחודש זה יקר לך, אין לי מה להציע לך. (רק אומר שמה שאני מציע יותר יציב ומהיר מהם)

אם אתה מחפש לכתוב לבד,
https://github.com/pedroslopez/whatsapp-web.js

@mekev אמר באבטחת מידע:

בהנחה שההגנה הקיימת בשרת וSQL תקינה ומעולה בפני עצמה

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

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

בנוסף, גם אם יצליחו להשיג את הפרטים, אין אפשרות (בקלות. הכל אפשרי) לתקשר ככתובת IP שלא שייכת אליהם, כך שאם הגבלת את שרת הSQL לכתובות ספציפיות - אתה אמור להיות מוגן.

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

בקיצור, אם חשוב לך אבטחת מידע - אתה לא אמור לחשוף שום דבר לרשת אלא ליצור חיבור VPN בין הרשתות

@nigun
אני בעד ואצטרף לפיתוח.
הספריה שבה השתמשת כבר לא בפיתוח זה נראה, הייתי הולך על https://github.com/emersion/go-smtp
ומוסיף ניהול מעל הDNS בדומה למה ש forwardemail עושים

@נהראל
להתקין את אנגולר הצלחת.
אתה מנסה ליצור פרויקט בתוך תיקית windows/system32 ולשם אין הרשאות לcli.

@שואף אמר בהתייעצות לגבי שידרוג מערכת קיימת:

מה דעתכם? איך היים ניגשים לזה?

חד וחלק DB.

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

@davidnead אמר בתבניות של API:

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

לא נכון, יש אפשרות להגדיר מודולים כקוד

@davidnead אמר בתבניות של API:

מה היתה המסקנה שלך? במה בחרת להשתמש?

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

@davidnead אמר בתבניות של API:

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

הגישה שלך מתאימה לWP, אני מניח שהיא לא פופולרית באיטרציה הנוכחית של עולם התכנות כי היום אוהבים כמה שפחות vendor lock in.

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

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

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

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

יש גם את directus, בזמנו הרגיש קצת בוסרי, מניח שכבר יותר טוב כיום.

בסופו של דבר, אם אתה לא מחפש את הUI שCMS נותן לך, אז אין שום עניין לחפש "תבנית" לAPI.
אתה כנראה סה"כ רוצה לכתוב איזה מבנה בסיסי של האובייקטים שלך, ולחשוף פעולות CRUD עליהם. שזה בגדול DB as API..
לזה כנראה keystone מעולה. ובטוח יש תחליפים דומים.
(הייתי מציץ על prisma אם לא מפריע לך לחשוב על שימוש בgraphql)

@yossiz אמר בחידה חביבה: להיכן נעלם הכסף?:

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

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