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

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

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

Template contains unsupported operations

רגע מה פתאום unsupported oprations? ומי בכלל דיבר על טמפלייטס? אבל מהר מאוד דברים מתחילים להתחבר. הפונקציה send_bulk_email של SES יודעת לקבל פרמטרים כדי לקסטם את האימייל לכל נמען בנפרד. פרמטרים בגוף המייל נכתבים בתוך סוגריים מסולסלים כפולים, ואצלי בפוסט היתה דוגמה בדיוק של סוגריים מסולסלים כפולים. האם SES חושב בטעות שתוכן המייל שלי דורש החלפת תבנית? האם הוא חושב שהסוגריים שבפוסט מגדירים פרמטרים? ואם זה המצב מה המשמעות של unsupported operations.

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

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

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

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

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

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

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